How ZedCloud works

ZedCloud is a hosting platform you drive from a visual canvas. What you see on the canvas is what runs.

Workspaces

A workspace holds one canvas: a project, a client, or an environment such as production. It has its own members, quotas, private network and activity log. You can have several, and copy one into environments like sandbox, QA and production.

Nodes

Each card on the canvas is a node: a real resource.

Kind	What it is
App	An API, backend or web app, from a container image, GitHub repository or uploaded folder
Static site	Files served as a website, no build
Cron job	A command that runs on a schedule
Linux box	A full Linux machine with root, systemd and Docker
Domain	Your own domain, routed to apps, sites or boxes
Database, cache, storage, AI gateway, secrets, observability	Managed data services

Every node starts private: other nodes in the workspace can reach it, but it has no web address. Switch it to Public to give it one.

Links

A link is a line between two nodes. Linking an app to a database, cache, bucket or other service injects that service’s connection details into the app as environment variables (DATABASE_URL, REDIS_URL, S3_BUCKET…). Nobody copies passwords around. Linking a Domain to an app routes the domain’s traffic to it.

shop.example

running

HTTPS on

web

running 2/2

main@a1f9c2e

3 env

orders

running

Postgres · 3 accounts

Standard · local

sessions

running

Valkey

photos

running

Object storage · 2 GB

A domain routes to the app; the app is linked to a database, a cache and a bucket, so it gets DATABASE_URL, REDIS_URL and the S3_ variables.

Staging and Deploy

Nothing changes on its own. New nodes, links and deletions are staged: they show in yellow and wait in the orange Deploy bar. When you’re ready:

1. Click the summary to see every pending change. Discard any you don’t want.
2. Press Deploy and review the plan: what will be created, changed or removed, and how much memory and CPU it adds.
3. Confirm. Everything is applied at once, with per-node progress.

Edits to settings of a running node are saved right away and marked not deployed yet until the next deploy. A workspace can require approval so a second person signs off every deploy.

New versions without downtime

When an app gets a new version, ZedCloud starts it next to the old one, waits until it is healthy, then switches traffic. If the new one fails, the old one keeps serving. The previous version is kept for a few minutes, so Switch back is instant. See Deploys and rollbacks.

Under the hood

• Each app runs in its own container under gVisor, a sandbox that adds a second kernel between your code and the server.
• Each workspace has its own private network. Apps in different workspaces can’t see each other.
• All traffic arrives over HTTPS. Certificates are issued and renewed automatically.
• Secrets and environment values are encrypted at rest and never shown to tokens, the CLI or AI agents.