Skip to main content
A new forge project is set up to deploy to Reliant’s own hosting. Its staging and prod environments already point there, so publishing is one command from the project directory, with no cluster, registry or DNS to arrange first:
Ask the agent in your project to “deploy it” and it takes this same path. The dev environment stays on your machine; only staging and prod are hosted.

​
What gets hosted

Hosting runs three kinds of workload: services (your Go API), workers (background processors) and jobs (one-off tasks such as the database migration that runs before each rollout). Your frontend is published separately as a static site on Reliant’s static hosting and CDN, and every workload and site gets a generated hostname the moment it deploys. Your app’s database is a managed Postgres: a dedicated database the platform creates for the environment, retained if you delete the environment. Your services receive its connection string automatically, and it is reachable only from inside the platform, so migrations run as part of the deploy rather than from your laptop. Because the frontend is served as static files, a hosted frontend must be a static export. New forge frontends are scaffolded that way by default. A frontend that needs a server at request time (server actions, middleware) ships as a workload instead.

​
The free tier and billing

One static site per organization is free, with no billing needed. Everything else, meaning any hosted service, worker or job, the managed database, or a second static site, needs an active Reliant Compute plan. Set one up under Settings → Billing; plan details and prices are shown there. Compute plans are bought per user and attach to that user’s first organization, so the person who sets one up is whoever can manage billing for the organization. You do not have to set up billing before your first deploy. If the organization has no plan, the deploy is queued, not refused. Reliant builds and records the release as usual, then holds it. Nothing is running yet, and nothing needs to be re-run: once billing is set up, the hold is released automatically and the deploy goes live. In the meantime:
  • forge env deploy prints one block (what it waits on, why, what to do, a link, and that there is nothing to re-run) and exits with code 7. Seven means “queued on a person”, not “failed”; a CI job can treat it differently from a real error. --json reports the same facts, and forge env status <env> also exits 7 while the deploy is queued.
  • forge env deploy --wait (or forge env status <env> --wait) blocks until the deploy is live.
  • The environment’s page under Forge in the Reliant app shows a “Waiting on billing” banner. Someone who can manage billing gets a Set up billing button that returns them to the environment afterwards; anyone else is told that only an admin can set it up, with a Copy link button to send along. The Overview lists the release with a “Waiting on billing” badge, the sidebar marks the environment “Queued”, and a desktop notification tells you once when the deploy goes live or fails.
  • A newer deploy to the same environment replaces a queued one.
Some deploys are refused rather than queued, with the reason printed: when the deploy asks for more than your plan allows, when the plan cannot be determined (retry), or when your spend cap has been reached. The spend cap is deliberate: it can clear on its own at the start of a billing period, and a deploy should not fire unattended then.

​
Secrets

Hosted environments keep their secrets in Reliant’s managed store, and a workload that reads a secret needs a value set before it can use it: deploys that need an unset secret fail until it is set. Set them from the command line (forge secret set --env prod STRIPE_SECRET_KEY) or in the app, then deploy. See Secrets for how values reach your workloads and why you can never read one back.

​
Domains

Every site and exposed workload answers on a platform hostname straight away. To serve your own, such as app.example.com, claim the domain and bind it to an environment; Reliant obtains the certificate. See Custom Domains.

​
Credentials

When you are signed in to Reliant, forge uses your session: there is no separate forge login, whether you run reliant forge ... yourself or an agent does. Standalone forge outside Reliant signs in with forge login, and CI uses a token supplied through the environment’s token variable.

​
What hosting does not run

Hosting shares machines between customers, so it refuses anything that needs control over the cluster. The deploy tells you before publishing, naming the workload and the field.

​
Hosting somewhere else

Hosting is the default, not a requirement. The scaffolded environment files include commented-out bindings for a Kubernetes cluster you operate, your own storage bucket and CDN for the frontend, or Docker Compose. Rebind a workload and forge deploys it there, with the same releases and promotion flow. A project can mix both: hosted services beside an operator that runs on your own cluster, for instance. Agents can load the deploy/hosting skill for the exact edits. Secrets, Custom Domains, and Settings → Billing in the app for plans and spend caps.