Quickstart

This guide takes you from a first sign-in to a live URL on your cluster in five steps, with no agents to install. If you register a cluster you already have, it takes about 15 minutes. If ZopDay provisions a new cluster for you, add 15 to 30 minutes for the cluster to come up.

Activity → Provisioning Jobs: every infrastructure change as a step-by-step job with its status, progress, and duration.

Before you start

• A cloud account you can connect: an AWS account, GCP project, or Azure subscription where you can create an IAM role, service account, or service principal with the permissions on Cloud permissions. On GCP and Azure, registering a cluster needs only the cluster-registration subset; provisioning needs more. On AWS, registering a cluster needs provision access.
• A Git repo with a working application. Any language Railpack auto-detects works (Node, Python, Go, Java, Ruby, and others), or you can supply a Dockerfile.
• For BYOC to an existing cluster: an EKS, GKE, or AKS cluster on that cloud account. On AWS, registering an existing EKS cluster needs the account connected with ZopDay Provision access; WIF-Assume Role, IAM User (Static Keys) and Temporary Credentials accounts all qualify. If you have no cluster, ZopDay can provision one in step 3.

Steps

1. Sign in and create your organisation

   Sign in at zop.dev/signin with GitHub, Google, SSO, or email. If you signed in through the shared zop.dev sign-in page, pick ZopDay on the product picker that follows.

   

   ZopDay sign-in; continue with GitHub, Google, SSO, or email, or create an account.

   On first sign-in, ZopDay creates your organisation and a first team. The organisation is named from your email address: priya.sharma@acme.com becomes Priya Org with a Priya Team. You can rename both later. ZopDay asks you to type a name only if it can’t derive one from your email. An optional step then lets you invite teammates and give each a role. You can skip it.

   If your organisation uses SAML SSO, ZopDay support configures it during onboarding. Contact your account team to enable it before you sign in. See Authentication.

2. Connect a cloud account

   Go to Settings → Cloud Accounts and click Add Cloud Account. Pick AWS, GCP, or Azure, then an authentication method. ZopDay verifies the credential against your cloud before it saves anything.

   AWS

   WIF-Assume Role (recommended): a keyless cross-account IAM role that ZopDay assumes, so no long-lived secret is stored. IAM user access keys and temporary STS credentials are also accepted.

   GCP

   One-Click Connect (recommended): sign in with Google, and ZopDay creates and manages a dedicated service account in the project. You need permission to administer the project’s IAM. Alternatively, upload a Service Account Key (JSON) that you manage yourself.

   Azure

   Service Principal (recommended): an app registration and client secret. Alternatively, use Workload Identity Federation, which relies on federated credentials, so there is no client secret to store.

   Cloud permissions lists the required permissions. For the BYOC quickstart, you need only the cluster-register subset. If you later want ZopDay to create infrastructure, grant the full provisioning permissions then.

   Credentials are encrypted at rest (AES-256-GCM) and are never returned through any API. ZopDay passes them only to the services that act on your account and to the GitHub Actions runner that builds and installs for you, which uses them to mint short-lived access for each run.

3. Register a deployment space

   A space is a Kubernetes cluster that ZopDay can deploy to. You can register one you already have, or have ZopDay provision a new one:

   • Have a cluster already? On AWS, first go to Settings → Cloud Accounts, open the account’s menu, choose Manage Clusters, and click Register on the cluster. This adds an EKS access entry for ZopDay, so no manual RBAC binding is needed on EKS. Then, on any cloud, open Infrastructure, select the discovered cluster, and click Enable to register it as a space. ZopDay uses your cloud credentials to mint an ephemeral kubeconfig for each deploy, valid for 13–45 minutes depending on the cloud. On GKE and AKS, check that ZopDay is bound in the cluster’s RBAC; see Bind ZopDay in cluster RBAC.
   • Need a fresh cluster? Go to Infrastructure → Provision → Kubernetes Cluster and pick the cloud account, region, and size. ZopDay provisions an EKS, GKE, or AKS cluster end to end (typically 15 to 30 minutes) and registers it as a space. In the wizard’s Components tab, select NGINX Ingress Controller and Cert Manager so they install with the cluster; the selection starts empty. Any of them still missing at your first service deploy is installed then, along with the Prometheus Stack (and, on AWS, Cluster Autoscaler and the EBS CSI driver). See Cluster provisioning.

   The cluster appears on Infrastructure (Graph or List view) with its status, region, and provider. ZopDay keeps the cluster’s status (active or inactive) in step with what it discovers on your account.

4. Create a project and environment

   Projects organise your services. Each environment in a project binds to a space and a namespace.

   1. Click New Project in the sidebar. Name it after your service or team (for example payments or platform). Then choose where it deploys: ZopCloud (fully managed, where it is enabled for your organisation) or Your own cloud, where you pick the cluster or VM as the deployment target. Projects are scoped to the organisation.
   2. Inside the project, click Add environment. Enter a name (for example prod or staging), pick a registered space, and pick the namespace ZopDay should deploy into, or create one. You can also bind a registry integration.

   The hierarchy is project → environment → deployments. A deployment’s infrastructure fields (space, namespace, registry) come from its parent environment.

5. Push your first deploy

   1. On the environment canvas, click Add service and choose your repo and branch. ZopDay uses Railpack to detect the language and build approach. You don’t need a Dockerfile, but ZopDay uses one if it is present.
   2. Run 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. The canvas opens the live rollout view for the service, and each stage streams to an append-only timeline in real time. The Build stage runs in GitHub Actions and streams its logs back to the pipeline view.
   4. Once the service is active, open it on the canvas. The service drawer’s Overview tab shows its public URL, the live revision, and the git source. The other tabs are Revisions, Observability, Network, Databases, and Settings.

   The phases of every deploy:

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

What just happened

• No agent installed on your cluster. For each deploy, ZopDay mints a short-lived kubeconfig (13–45 minutes depending on the cloud) from your cloud account credentials. The deploy pod holds no standing credentials.
• Your registry, not ours. The built image goes to the registry you configured on the environment. If you skipped that, it goes to the cloud-default registry (ECR, Artifact Registry, or ACR) on the space’s cloud account.
• Audit captured. Activity → Audit Logs records every change you make (deploy, rollback, env edit), with the actor, request and response body, and timestamp. Reads an AI assistant makes over MCP are recorded too, with the request only.

Troubleshooting

Next steps