> ## 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. # Hosting on Reliant > What Reliant hosting runs for a forge project, what it costs, what a queued deploy means, and what it refuses 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, show the plan, deploy it reliant forge env deploy prod --from staging # ship exactly what staging runs ``` 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. How releases, plans and promotion work is the same on every target and is covered in [Environments & deploys](/forge/environments-and-deploys); this page is about what hosting itself provides. ## What gets hosted Hosting runs three kinds of workload: **services**, **workers** (background processors) and **jobs** (one-off tasks such as the database migration that runs before each rollout). In a hosted environment, every service and worker in your project runs in one workload called `api` (the binary's `server` command), so the browser reaches every service at one origin with one sign-in cookie. Your frontend is published separately as a **static site** on Reliant's static hosting and CDN. 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, and `forge lint --static-export` names anything in your code that the export cannot serve (a dynamic `[id]` route, a server action, `cookies()`). A frontend that needs a server at request time ships as a workload instead. Telemetry is collected from the first deploy too: see [Observability](/forge/observability). ## Billing Anything that runs a process on Reliant's hosting needs an active Reliant Compute plan: every hosted service, worker and job, the managed database, and image builds. 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. Static sites are the exception. They run no process, just files behind the CDN, so an organization with no plan gets a free tier for them: * **One static site per organization**, counted across all of its environments. Deploying a second one is queued like any other billing hold (below) until you remove a site or set up a plan. * **1 GiB of storage.** Reliant keeps a release's files three times (live, its archive and the previous release), so in practice a release of about 340 MiB or less fits. A larger one is held with the size in the message; shrink the site or subscribe. * **10 GiB of traffic per calendar month** (UTC) for the organization. The organization's owner is notified at 80% and 100%, and past the limit the site answers `429` until the month rolls over. A project that is only a static site, such as a landing page, can therefore be published without a plan. A project with a hosted backend needs a plan for the backend, even though its frontend is static. ## Queued deploys 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", so a CI job can treat it differently from a real error. `--json` reports the same facts, and `forge env status ` also exits 7 while the deploy is queued. * `forge env deploy --wait` (or `forge env status --wait`) blocks until the deploy is live. * The environment's page in **Apps** (**Environments → \**) 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 environment is marked queued in the Apps navigation, 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. ## Stopping and deleting an environment `forge env stop ` suspends a hosted environment's workloads (they stop running and stop costing compute) and `forge env start ` resumes them. `forge env delete ` tears the environment down; its managed database is retained. These act on the hosted environment, unlike `forge env down`, which only stops the local processes `forge env up` started. ## 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 (`forge scaffold worker --kind cron`) 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 [Custom domains](/forge/custom-domains) | For any of these, bind that one workload to a cluster you operate and keep the rest hosted; see [Hosting somewhere else](/forge/environments-and-deploys#hosting-somewhere-else). ## Related topics [Environments & deploys](/forge/environments-and-deploys), [Secrets](/forge/secrets), [Custom domains](/forge/custom-domains), [Forge sign-in](/forge/sign-in), 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.