How Candor Deploy works

Candor Deploy is a flat-rate app platform: connect a GitHub repository, push, and your code is built and running in an isolated container behind HTTPS at its own URL. This page describes the actual pipeline — what triggers a build, where your app runs, and how the pricing model works — because if we’re running your code you deserve to know how.

Where it stands: Candor Deploy is in beta. It opens to a limited group of beta testers in August 2026 — join the list — and we expect the beta to run about 90 days before general availability. Everything documented here is the real, working platform beta testers get.

Everything below happens in the Deployments tab of the client area at my.candorhost.com. No CLI to install, nothing to configure on your machine beyond git push.

The pipeline, start to finish

1. Create a project. Click New project — a project groups one application’s services.
2. Connect GitHub. In a project, click + App to open the Deploy an app form, then click Connect GitHub. That opens GitHub’s own install page for the Candor Deploy app, where you choose exactly which repositories it can see — one, several, or all. When you finish, come back to the form and your repositories appear in the picker. Private repositories work: builds clone through a short-lived access token that expires within the hour. Prefer not to install anything? Paste a public repository’s Git URL instead — that works too, including the first automatic build.
3. Create the app. Pick a repository and a branch (main by default — pushes to other branches are ignored). The name is suggested from the repository; for a monorepo you can point at a subdirectory with the optional root directory field. The first build starts immediately.
4. We build it. The build clones your repository at the exact commit, then builds it with Nixpacks, which detects your stack — Node, Python, Go, Ruby, PHP, or a static site — with no YAML required. A Dockerfile in your repo is ignored unless you opt in — it’s usually there for local development rather than for deploying. You can watch the phases in the portal: queued → building → deploying → live.
5. It runs. Your app starts in its own isolated container and is serving on HTTPS at its URL — typically about a minute after the push.

What triggers a deploy

• Creating an app with a repository connected — the first build kicks off on its own.
• Every push to the deployed branch. GitHub notifies us the moment you push (we cryptographically verify the notification actually came from GitHub), and we build the exact commit you pushed. Pushes to other branches deploy nothing.
• A manual deploy — enter any commit SHA in the app’s Deployments tab.
• A rollback — every previous deployment in the history has a Rollback button; one click redeploys that commit.

Builds are honest about their limits: a build gets up to 2 CPU cores and 2 GB of memory, and one that runs longer than 15 minutes is stopped rather than left hanging. The build output for every deployment is kept — click any entry in the history to read exactly why it succeeded or failed.

Where your app runs

Each service runs in its own isolated container; new apps start with 512 MB of memory. That memory is a reservation, not a hope — it’s set aside for your container — and CPU isn’t metered.

Rollouts are zero-downtime by construction: the new version starts and must accept connections before the old one is retired. A build that can’t start never replaces the version that’s serving.

Your app just needs to listen on the port in the $PORT environment variable (8080 by default). Environment variables live in the app’s Environment tab — one KEY=value per line, stored as a secret, applied on the next deploy. Details in builds and configuration.

Your URL and HTTPS

Every app gets a generated hostname on candorhost.app — its service name plus your account number, like myapp-1042.candorhost.app — with a real Let’s Encrypt certificate, renewed automatically.

Custom domains are included on every plan. Add one in the app’s Domains tab and the portal shows the exact DNS record to create — a CNAME for a subdomain, an A record for an apex domain. Once your DNS points at us, the HTTPS certificate for that hostname is issued and renewed automatically; there is nothing to upload or configure. Full walkthrough: domains and HTTPS.

Logs you can actually read

Two kinds, both in the portal:

• Build output, kept per deployment — the Deployments tab’s history expands to show what the build did, trimmed to its most recent 2,000 lines with the trim clearly marked.
• Runtime logs, live in the Logs tab, refreshing every few seconds — your app’s own output, streamed as it happens and sanitized so it never leaks our infrastructure’s internals.

Databases, workers, and static sites

A project groups one application’s services — frontend, backend, worker, database. Alongside apps you can run:

• Managed databases — Postgres, MySQL, or Redis. Each has a Connect tab with its connection URI and credentials — and in an app’s Environment tab, the Attach control writes that URI into the app’s environment as DATABASE_URL (REDIS_URL for Redis). Databases are reachable only from your own apps, never from the internet. More in databases on Deploy.
• Workers — background processes with no public URL. The platform runs them, but the portal can’t create one yet; that control is coming.
• Static sites — the platform serves them without drawing on your memory pool, and they’re unlimited; today the portal deploys every repo as an app, so ask us to flip a site to static.

The price is a memory pool

Your plan is a pool of memory your services share. The numbers, from the pricing page:

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

The memory you assign to apps, workers, and databases adds up against the pool; the portal shows the meter at the top of the Deployments tab. If a new service wouldn’t fit, we refuse it up front with the exact arithmetic — never silently throttle. There are no per-app fees, no metered CPU, no egress meter, and the price you sign up at is the price you renew at. All plans include automatic HTTPS, custom domains, backups, and free migrations; billed monthly in USD, cancel anytime.

The uptime commitment is 99.9% monthly, with the math published in the SLA. When you need a human, Candid Support publishes the response times.

Go deeper

• Deploy quickstart — from signup to a live URL, step by step
• Builds and configuration · Databases · Domains and HTTPS
• Troubleshooting — when a build fails or an app won’t start

Questions this page doesn’t answer? Ask us — a straight question gets a straight answer.