# Quickstart

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

Source: https://zop.dev/docs/zopday/quickstart

---

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](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260602/a1dca216-4769-4529-898b-5bfc95a53a86-zopdayprovisioningjobs.png)

*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

**Note**

AWS (EKS) and GCP (GKE) support the full flow through to a live deploy. Azure (AKS) deploy is in preview / not yet GA: you can connect the account and provision or register an AKS cluster today, but the deploy step (Step 5) returns a clean error at the kubeauth boundary until AKS support is finalised.

## 1. Create a workspace

Sign in at [zop.dev/signin](https://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](https://zop.dev/docs/zopday/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](https://zop.dev/docs/zopday/cloud-setup/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.

**Note**

Credentials are encrypted with AES-256-GCM and stored against your org. They are never logged, never returned through any API, and never leave the cloud account's resource path.

## 3. Register a deployment space

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

**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.

**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](https://zop.dev/docs/zopday/provisioning/clusters).

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.

**Create a project**

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

**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

**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).

**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.

**Watch the pipeline**

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

  ```
  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.

**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](https://zop.dev/docs/zopday/pipelines)**: rolling / canary / blue-green strategies and health gates
- **[Rollbacks](https://zop.dev/docs/zopday/rollbacks)**: one-click reversal with build skipped
- **[Service connections](https://zop.dev/docs/zopday/concepts/service-connections)**: wire two deployments together with auto-refreshed env vars
- **[Cloud permissions](https://zop.dev/docs/zopday/cloud-setup/permissions)**: extending the minimum role to enable provisioning, autoscaling, and registry writes