> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reliantlabs.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy & host your app

> Publish a forge project on Reliant hosting — what runs where, the free static tier, what needs billing, what a queued deploy means, and how to host somewhere else

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:

```bash theme={null}
reliant forge env deploy staging     # build, push, cut a release, apply it
reliant forge env deploy prod        # the same, once staging looks right
```

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](/features/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](/features/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.

| Not available on hosting | Why |
| - | - |
| Cron-kind workloads | Not metered yet; a worker that runs its own scheduler is fine |
| Operators, RBAC, CRDs | No Kubernetes API access on shared machines |
| Sidecars, volumes, security-context and pod overrides | The platform builds the pod itself |
| Node selectors, tolerations, priority classes | The platform decides placement |
| Domains written into the workload spec | Domains are managed separately (see above) |

## 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.

## Related topics

[Secrets](/features/secrets), [Custom Domains](/features/custom-domains), and **Settings → Billing** in the app for plans and spend caps.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.