Skip to main content Skip to content

Quickstart

Sign in, connect a cloud account, register a cluster, and deploy your first service in under 15 minutes.

5 min read Last updated: 

This walks you from a cold sign-in to a live URL on your cluster. Five steps, ~15 minutes, no agents to install.

ZopDay Provisioning Jobs activity log showing dozens of recent jobs (cluster creates, datastore connections, deletes) across us-prod, us-staging, eu-prod, eu-staging, apac-prod with action type, status, progress, duration, and timestamp

Provisioning Jobs; every cluster, datastore, and network operation as an auditable activity log.

Prerequisites

  • An AWS, GCP, or Azure account where you can create or attach an IAM role / service account / service principal
  • A Git repo with a working application (Node, Python, Go, Java, Ruby; anything Railpack auto-detects, or a Dockerfile if you have one)
  • For BYOC deploys to an existing cluster: a Kubernetes cluster you can grant ZopDay access to via the cloud account credentials

1. Create a workspace

Sign in at zop.dev/signin with Google, GitHub, or your work email. On first sign-in you’ll be asked for an organisation name; pick a short, lower-case identifier (e.g. acme). This becomes the URL prefix for your workspace.

If your organisation uses SAML SSO, note that SAML/SSO is configured by ZopDay support during onboarding; contact your account team to enable it before you sign in. See Authentication.

2. Connect a cloud account

Settings → Cloud accounts → Connect. Pick AWS, GCP, or Azure. The wizard walks you through three flows:

AWS

Create an IAM role with the trust policy ZopDay shows you. Paste the role ARN. ZopDay validates the role via STS before saving.

GCP

Create a service account with the roles ZopDay lists. Upload the JSON key. ZopDay validates via a projects.get call.

Azure

Create a service principal in your tenant with the roles ZopDay lists. Paste clientId / clientSecret / tenantId / subscriptionId. ZopDay validates via subscriptions/get.

Required permissions are on Cloud permissions. For BYOC quickstart you only need the cluster-register subset; full provisioning permissions can be granted later if you want ZopDay to create infrastructure.

3. Register a deployment space

A space is a Kubernetes cluster ZopDay can deploy to. Two paths:

  1. Have a cluster already?

    Settings → Cloud accounts → click the connected account → pick a cluster from the discovered list → Register as space. ZopDay mints an ephemeral kubeconfig (per-deploy, short-lived: 13-45 minutes depending on cloud) using your cloud credentials. Nothing is installed on the cluster.

  2. Need a fresh cluster?

    Provisioning → New provisioning job → Cluster → pick provider, region, size. ZopDay provisions an EKS, GKE, or AKS cluster end-to-end (4–7 minutes), registers it as a space, and applies hardened defaults (RBAC, Network Policies, Pod Security Standards). See Cluster provisioning.

The space appears on Settings → Spaces with status, region, and provider. Cluster reachability is probed every 60 seconds; if it goes inactive, all UI flows that depend on it gate cleanly rather than throwing cryptic SDK errors.

4. Create a project and environment

Projects organise your services. Environments inside a project bind to a space + a namespace.

  1. Create a project

    Projects → New project. Name it after your service or team (e.g. payments, platform). Org-scoped.

  2. Create an environment in it

    Inside the project → New environment. Name (e.g. prod, staging), pick a registered space, pick the namespace ZopDay should deploy into (or create one). Optionally bind a registry integration.

The hierarchy is project → environment → deployments. Deployments are catalog rows in the config service; their infra fields (space, namespace, registry) hydrate from the parent environment.

5. Push your first deploy

  1. Add a deployment to the environment

    Environment → Add deployment. Paste the repo URL, pick a branch, optional canvas position. ZopDay auto-detects the language and build approach via Railpack; no Dockerfile required (one is respected if present).

  2. Push to the branch

    git push to the configured branch. The GitHub webhook notifies ZopDay, which queues a new deployment and picks it up automatically.

  3. Watch the pipeline

    Deployment detail page → Pipeline tab. The phases stream in real time:

    Terminal window
    Resolve → Clone → Detect → Build (GitHub Actions) → Deploy → WatchRollout → Active

    Each stage streams to an append-only timeline. The Build stage runs in GitHub Actions and streams its logs back to the pipeline view in real time.

  4. Get the live URL

    Once the deployment is active, the deployment header shows the live URL. Click it.

What just happened

  • No agent installed on your cluster; kubeauth mints a short-lived kubeconfig per deploy (13-45 minutes depending on cloud) from your cloud account credentials. The deploy pod holds zero standing credentials.
  • No image registry of ours in the path; the image hash is pushed to the registry you configured (or to ZopDay-provided ECR/Artifact Registry/ACR if you skipped registry config).
  • Audit captured: every API call (deploy, rollback, env edit) is in the audit log with actor, body, response, and timestamp.

Where to next

  • Pipelines: rolling / canary / blue-green strategies and health gates
  • Rollbacks: one-click reversal with build skipped
  • Service connections: wire two deployments together with auto-refreshed env vars
  • Cloud permissions: extending the minimum role to enable provisioning, autoscaling, and registry writes
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001 · zero-trust· 30% average cloud cost cut· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001 · zero-trust· 30% average cloud cost cut· 4 platforms · 1 console·