Quickstart: first deploy in ten minutes

This walks you from access to a live app, using the actual buttons in the portal. If you can git push, the whole thing takes about ten minutes — most of which is GitHub asking you which repositories to share.

1. Get access

Candor Deploy is in beta — public ordering opens with the beta in August 2026. Join the beta list and we’ll email your invite as seats open; when we grant access, your Deploy account is provisioned automatically, so there’s nothing to wait for on our side. The plan is a pool of memory your apps share — flat monthly price, no per-app fees, no metered egress (planned pricing):

	Solo	Studio	Org
Price / month	$12	$25	$50
Memory pool	1 GB	4 GB	10 GB
Apps or workers	2	10	25
Databases	1	3	10
Static sites	unlimited	unlimited	unlimited

2. Open the Deploy area

Log in at my.candorhost.com, open your Candor Deploy service, and choose the Deployments tab. That’s the whole management portal: at the top you’ll see your plan and a meter of how much of your memory pool is in use.

3. Connect GitHub

Deploying a public repository? Skip this — paste its Git URL straight into the repository field in the next step instead.

For a private repository, connect GitHub once and it works everywhere after. Open a project (New project on the dashboard makes an empty one if you don’t have one yet) and click + App — the form that opens has a Connect GitHub button at the top.

1. Click Connect GitHub. A new tab opens on GitHub’s install page for the Candor Deploy app.
2. Choose the account or organization, pick which repositories to share (all, or just the one you’re deploying), and install.
3. GitHub lands you on a “GitHub connected” confirmation. Close that tab and return to the portal — the form notices the new installation on its own and shows a “GitHub connected” toast.

Your repositories now show up in every repository picker in the portal, including Deploy’s, next.

4. Deploy

A project is a workspace for one application’s parts — frontend, backend, cache, database. Click Deploy on your dashboard:

1. Project — pick an existing one from the dropdown, or leave it on New project and name it (it defaults to your repo’s name once you’ve picked one, and it’s fine to name it after the application rather than the repo).
2. Repository — pick your repository from the dropdown (or paste a URL). Branch defaults to main (the dropdown pre-fills your repo’s default branch once you pick it).
3. Click Detect. We read the repository and work out what it is — a single app, or a whole monorepo with its databases.
4. Review what we found, then click Deploy:
   • Every app we recognized is listed and ready to go. Uncheck anything you don’t want deployed yet; if we found more than one, the app marked Public is the one your custom domain attaches to (move the badge first if we guessed wrong).
   • Found an app but couldn’t tell how to start it? That row asks for its start command right there — Deploy stays disabled on it until you fill that in, rather than us failing the build later.
   • Couldn’t recognize the repository at all? The screen opens with one blank row instead — describe your app and deploy that.

The first build starts as soon as you click Deploy — open the project and you’ll find it in the app’s Deployments tab. (If no build appears, deploy a commit by SHA — see step 7.)

5. Watch it build

Open the app you just created and go to its Deployments tab. Every deployment moves through four phases: queued → building → deploying → live.

The build itself uses Nixpacks, which detects your stack — Node, Python, Go, Ruby, PHP, static — and produces a container image. A Dockerfile in your repo is ignored unless you opt in — which keeps a stale local-dev Dockerfile from breaking your deploy. A build has 15 minutes to finish before it’s stopped. One thing your app must do: listen on the port given in the PORT environment variable. Both are covered in Builds and configuration.

• Build output: in the deployment history, click any deployment to expand its build log — including exactly why a failed build failed. Failed build? Start with Troubleshooting.
• Runtime logs: once the app is running, the Logs tab streams its output live, refreshing every few seconds.

6. Find the live URL

When the deployment reaches live, your app is serving at its generated address:

https://<app-name>-<your-client-id>.candorhost.app

The URL is shown at the top of the app’s page, next to a Visit button. HTTPS is automatic — a real certificate, issued and renewed for you. Want your own domain instead? The app’s Domains tab shows you the one DNS record to set: Domains and HTTPS.

7. Push an update

This is the part you’ll do every day, and it’s the shortest:

git push

Every push to the connected branch builds and deploys automatically — the phases in the Deployments tab, same as the first time. (An app follows the branch shown in the Branch field when you created it — your repo’s default branch if you picked it from the dropdown, otherwise main.)

Two escape hatches live in the same tab: Deploy a commit rebuilds any commit you name by SHA, and every previous deployment in the history has a Rollback button that redeploys that exact commit.

Where to go next

• Environment variables — the app’s Environment tab, one KEY=value per line. Saved values apply on the next deploy.
• Add a database — + Database on the project card gives you managed Postgres, MySQL, or Redis. Its Connect tab has the connection URI, or use Attach a database in your app’s Environment tab to drop it straight into DATABASE_URL (REDIS_URL for Redis). More in Databases on Deploy.
• How it all fits together — How Candor Deploy works.

Stuck? Ask us — we reply within one business day, per the same support standard every plan gets.