Provisioning | ZopDev Developer Docs

Stand up cloud infrastructure end-to-end from a single wizard. ZopDay creates VPCs, Kubernetes clusters, VMs, datastores, registries, and load balancers across AWS, GCP, and Azure, using the same credentials you connected for discovery and scheduling.

How provisioning runs

No OpenTofu, no remote agents: ZopDay talks to the cloud SDKs (AWS, GCP, Azure) directly. After a fresh cluster is up it is registered as a Deployment Space automatically, and a resource sync starts so it appears in your inventory.

What you can provision

Category	AWS	GCP	Azure
Kubernetes	EKS	GKE	AKS
VMs / compute	EC2 + ASG + ALB / NLB	Compute Engine + MIG + GCLB	VM Scale Sets + Azure LB
Datastores	RDS (MySQL / Postgres), ElastiCache (Redis)	Cloud SQL (MySQL / Postgres), Memorystore (Redis)	Database for MySQL / Postgres, Azure Cache for Redis
Registry	ECR	Artifact Registry	ACR
Networking	VPC, Subnets, VPC Peering	VPC, Subnets, DNS Zones	VNet, Subnets
In-cluster components	Cluster and VM components (ingress, observability, cert-manager, and platform add-ons), installed through the Components endpoints

How it works

Pick a space — choose a connected cloud account and a region. ZopNight discovers existing VPCs, subnets, and DNS zones in the background so the wizard can offer real options instead of free-text fields.
Pick a resource type — cluster, VM, datastore, or component.
Configure — instance size, version, networking, backup retention, etc. Sensible defaults are pre-filled.
Review — ZopNight shows the IAM operations it will perform and the estimated monthly cost before any action runs.
Provision — ZopDay applies the changes through cloud SDKs; progress streams to the UI; the request is recorded in the audit log. On success, freshly created clusters auto-register as spaces and resources flow into Reports + Recommendations.

RBAC

Provisioning ships with four policy categories so platform teams can delegate provisioning without granting full tenancy admin:

Policy	What it grants
`space:view / create / update / delete`	Manage Deployment Spaces (cloud account + region pairs targeted for provisioning)
`provisioning:view / create / update / delete`	Run, monitor, modify, and tear down provisioning jobs
`service:view / create / update / delete`	Manage in-cluster components attached to a space
`deployment:view / create / update / delete`	Manage application deployments

Default System roles inherit these policies; custom roles need explicit grants. See Roles & Permissions for how to assemble them.

Provisioning jobs

POST /provisioning-jobs

Submit a new provisioning job for a cluster, VM, datastore or network.

The body names what to create (resourceType) and where (provider, region, cloudAccountId). resourceType is one of cluster, vm, postgres, mysql, redis or vpc. The fields inside config depend on the resource type. kind defaults to create; send "kind": "update" with a resourceUid to change an existing resource.

curl -X POST https://api.zop.dev/provisioning-jobs \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "platform-prod",
    "provider": "aws",
    "region": "us-east-1",
    "resourceType": "cluster",
    "cloudAccountId": "1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d",
    "config": {
      "k8sVersion": "1.30",
      "nodeType": "m5.large",
      "minNodes": 2,
      "maxNodes": 6,
      "existingVpcId": "vpc-0abc"
    }
  }'

curl -X POST https://api.zop.dev/provisioning-jobs \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "checkout-db",
    "provider": "aws",
    "region": "us-east-1",
    "resourceType": "postgres",
    "cloudAccountId": "1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d",
    "config": {
      "engineVersion": "16.3",
      "instanceClass": "db.t3.medium",
      "storageGb": 50,
      "multiAz": true,
      "backupEnabled": true,
      "backupRetentionDays": 7
    }
  }'

curl -X POST https://api.zop.dev/provisioning-jobs \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "checkout-edge",
    "provider": "aws",
    "region": "us-east-1",
    "resourceType": "vm",
    "cloudAccountId": "1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d",
    "config": {
      "mode": "asg",
      "instanceType": "m5.large",
      "minInstances": 2,
      "maxInstances": 6,
      "image": "ubuntu-22-04-lts",
      "loadBalancer": true,
      "exposePorts": [80, 443]
    }
  }'

GET /provisioning-jobs

List provisioning jobs, with status.

GET /provisioning-jobs/{id}

Get a job's full state — phase, per-step output, and any errors.

PATCH /provisioning-jobs/{id}

Update lightweight job fields (name, tags) without re-running the pipeline.

DELETE /provisioning-jobs/{id}

Tear down a previously created cluster, VM, datastore, or network.

POST /provisioning-jobs/{id}/retry

Retry a failed job from the last successful step. Useful for transient failures (rate-limited cloud API, throttled subnet creation).

Databases under a job

Datastore jobs are the parent of one or more databases — logical schemas the application code will connect to. Each database has its own credentials and is provisioned by issuing CREATE DATABASE + CREATE USER against the parent server.

POST /provisioning-jobs/{jobID}/databases

Create a database on the parent datastore.

curl -X POST "https://api.zop.dev/provisioning-jobs/job_abc/databases" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "name": "checkout", "owner": "checkout_app" }'

GET /provisioning-jobs/{jobID}/databases

List databases under a job.

GET /provisioning-jobs/{jobID}/databases/{dbID}

Get a database with its connection metadata (server, port, secret reference).

DELETE /provisioning-jobs/{jobID}/databases/{dbID}

Drop the database and revoke its user.

Connections

A connection is a stored set of credentials (host, port, user, secret reference) an application fetches at deploy time. Connections live either at job scope (one set of credentials shared across all databases on the server) or at database scope (one set per database).

Job-scoped

POST /provisioning-jobs/{jobID}/connections

Create a job-scoped connection.

GET /provisioning-jobs/{jobID}/connections

List job-scoped connections.

GET /provisioning-jobs/{jobID}/connections/{connID}

Get a job-scoped connection by ID.

DELETE /provisioning-jobs/{jobID}/connections/{connID}

Delete a job-scoped connection (does not drop the database user).

Database-scoped

POST /provisioning-jobs/{jobID}/databases/{dbID}/connections

Create a connection scoped to a specific database.

GET /provisioning-jobs/{jobID}/databases/{dbID}/connections

List connections scoped to a database.

GET /provisioning-jobs/{jobID}/databases/{dbID}/connections/{connID}

Get a database-scoped connection.

DELETE /provisioning-jobs/{jobID}/databases/{dbID}/connections/{connID}

Delete a database-scoped connection.

Components

Cluster and VM components (ingress controllers, observability agents, cert-manager and similar add-ons) are installed onto a Deployment Space through the components endpoints.

GET /components

List the component catalog for a target (?targetType=), or poll an install (?actionId=).

POST /components

Install or re-apply a component on a space. Returns an actionId to poll.

curl -X POST https://api.zop.dev/components \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "spaceId": "<space id>",
    "targetType": "cluster",
    "component": "ingress-nginx"
  }'

targetType is cluster for a Kubernetes space or vm for a VM space.

POST /components/{component}/upgrade

Upgrade an installed component.

VPC Peering on Architecture

VPC peering connections are first-class on the Architecture canvas alongside transit gateways and interconnects. When you provision a cluster or datastore in a peered VPC, the link is rendered automatically and click-throughs land on the discovered peering connection’s detail.

See Resources for the full discovered-resource model and Deployment Spaces for cluster registration.