Quick Deploy (ZopCloud)

Quick Deploy is the fastest path from a git repo to a live URL: pick the repo, name it, click. There’s no cloud account to connect and no cluster to register, because the deploy lands on ZopCloud, a managed VM pool ZopDay operates on your behalf. It’s ideal for demos, prototypes, and getting a feel for the platform before wiring in your own cloud.

Creating a project on ZopCloud; pick the managed option and deploy in seconds with no cloud account to connect.

ZopCloud vs your own cloud

	ZopCloud (Quick Deploy)	Your cloud (BYOC)
Cloud account needed	No	Yes
Cluster/VM to register	No	Yes
Where it runs	A managed VM pool ZopDay operates	Your AWS / GCP / Azure account
Best for	Demos, prototypes, first-run	Production and anything you own

Under the hood, ZopCloud is the same VM substrate as a customer-provisioned VM space; the difference is that the VMs are owned and run by ZopDay, and surfaced to your workspace as shared, read-only infrastructure.

Quick Deploy

1. Create a project on ZopCloud

   Click New project, name it, and pick ZopCloud (the recommended, fully managed option) as the deploy target. No cloud account to connect.

2. Add a service from your repo

   Add service, choose Repository as the source, and pick your git repo. ZopDay detects the framework and port automatically (the same repo analysis used everywhere).

3. Deploy

   ZopDay submits the deployment against the shared pool and takes you to the live progress page. When it goes active, you get a live URL; the “Live at” preview shows the exact host before it’s ready.

4. Verify (and if it fails)

   You know the deploy is live when the progress page reaches Active and the URL responds. If a stage fails, the progress page shows the failing step and its error; fix the cause and redeploy. The same build-log watchdog used on the VM substrate recovers a deploy whose success callback was lost, so a build that pushed successfully still lands even if the callback did not arrive.

Custom Deploy

When you need more control than one-click, the Custom Deploy wizard exposes the fields the one-click path fills in for you:

• Expose config: hostname / domain, port, and path the service is served on
• Environment variables: keys and values injected into the container (see the warning below on how values are handled)
• Advanced settings: resource sizing and health-check overrides for the deployment

Managing a Quick Deploy

The VM-pool detail page gives you:

• Domains attached to the pool
• Install actions for the pool’s components
• The Deployments list running on the pool
• A Jobs card showing the install-plane action log

What a shared pool guarantees

• Tenant isolation. ZopCloud VMs are shared infrastructure, but your deployments, domains, and env vars are yours. Cross-tenant rows can never displace your own resources in your infrastructure view.
• TLS and routing handled. Same Caddy-based TLS and multi-service routing as any VM substrate.
• A clean migration path. When you’re ready for production, connect your own cloud account and deploy to a cluster or your own VM space; the catalog concepts (projects, environments, deployments) are identical.

Limits of the shared pool

ZopCloud is sized for evaluation, not production. Expect capped resources per deployment, a single managed region (you don’t choose where the pool runs), and no capacity or uptime guarantees; idle deployments may be reaped to keep the shared pool healthy. When you need guaranteed capacity, a specific region, private networking, or an SLA, graduate to your own cloud (below).

When to graduate off ZopCloud

Quick Deploy is deliberately a starting point. Move to your own cloud when you need production SLAs, data residency, private networking, dedicated capacity, or your own compliance boundary. Everything you learned in Quick Deploy (the deploy flow, rollbacks, service connections) carries straight over. See the Quickstart for the BYOC path.