RHost Documentation

Introduction#

What is RHost?#

RHost is a business platform that brings your domain, DNS, apps and data together under one account. Register a domain or bring one you own, run its DNS, and deploy web services, workers, cron jobs, static sites and managed databases straight from Git — paying only for what you switch on.

Think of it as two things working together. First, a domain & DNS platform: buy a new domain through RHost, or bring one you already own, and manage all its DNS from one dashboard. Second, a hosting platform: deploy web services, workers, cron jobs, static sites and managed Postgres, MySQL or Redis straight from Git — on RHost's own infrastructure, or on a server you already own. You pay only for what you switch on.

One account covers all of it. You and the people you invite sign in once, and the same console carries your domains, your DNS, everything you have deployed, and the bill for it.

RHost's DNS is powered by PowerDNS — a proven, high-performance open-source nameserver used by some of the world's largest DNS operators. Changes you make in the dashboard are reflected in the DNS within seconds.

How it works#

The flow to get your domain live on RHost is straightforward:

1. 1

   Add your domain

   Enter your domain name in the Domains dashboard. RHost immediately creates a DNS zone and seeds it with default SOA and NS records.

2. 2

   Set up your DNS records

   Add all the records your domain needs — A, AAAA, MX, CNAME, TXT, and so on. If RHost can auto-import your existing records from your current provider, it will do so automatically.

3. 3

   Point your nameservers

   Log in to your domain registrar and update the nameservers to RHost's nameservers. Once propagated, all DNS queries for your domain will be answered by RHost.

Platform nameservers#

When adding a domain to RHost, you will need to update your nameservers at your registrar to point to the following:

Getting Started#

Create an account#

Navigate to rhost.rw/auth/signup and complete the three-step registration form:

• Step 1 — Personal information: first name, last name, email address, and optional phone number.
• Step 2 — Organisation details: company name, address, city, and country (all optional).
• Step 3 — Password: choose a strong password, confirm it, and accept the terms of service.

You can also sign up using your Google or GitHub account via the OAuth buttons on the signup page. After registration, a verification email will be sent to your address.

Your account#

Your account groups your domains, DNS zones, and team members together — every domain belongs to your account. It's created automatically when you sign up; there's nothing to set up.

Team members can be invited to your account with their own roles and permissions.

Add your first domain#

Once you have a workspace selected, navigate to Domains in the sidebar. In the Add a domain you already own panel, type your domain name and click Add domain.

RHost will immediately:

• Create a DNS zone for your domain.
• Seed the zone with default SOA and NS records.
• Attempt to auto-import your existing DNS records from your current provider.

You will be redirected to the domain detail page where you can review imported records, add new ones, and eventually point your nameservers to go live.

Buying a Domain#

Search & availability#

To register a brand-new domain, go to Domains → Register and type the name you want. RHost checks availability live against the global registry (via RDAP) and shows you which extensions are free, which are taken, and the yearly price of each.

• Available — free to register right now, with its price shown per year.
• Registered — already owned by someone else. If you own it elsewhere, you can add it as an external domain or transfer it in instead.
• Unsupported — the extension (TLD) is not one RHost sells yet.

Registering a domain#

Pick one or more available domains and continue to checkout. You'll choose a registrant contact (the legal owner of the domain — see below), then pay securely by card. As soon as payment succeeds, RHost:

• Registers the domain in your name.
• Creates its DNS zone and points it at RHost's nameservers automatically — no manual nameserver step needed for domains bought here.
• Adds it to your Domains dashboard, ready for records.

Registered vs external domains#

RHost handles two kinds of domain. The difference is only about where the registration lives — both get the full DNS dashboard.

Domain contacts#

Every registered domain needs a registrant contact — the person or organisation that legally owns it. Manage these under Contacts. You can reuse one contact across many domains, and update details (address, phone, email) in one place.

Transferring a domain in#

To move a domain's registration to RHost, open Domains → Transfer in, enter the domain and the authorization (EPP) code from your current registrar, and submit. You can track the request's status and cancel it while it is still pending. Transfers follow the standard registry process, so they can take a few days to complete.

Domain Management#

Adding an external domain#

An external domain is a domain you registered at a third-party registrar (Namecheap, GoDaddy, Cloudflare Registrar, etc.) that you want RHost to manage DNS for. You do not need to transfer your domain registration — only the nameservers need to change.

Enter just the root domain (e.g. example.rw) without a trailing dot or any subdomain prefix. RHost normalises the input automatically.

Domain lifecycle#

Every domain in your inventory has two status indicators:

Pointing nameservers#

Once your DNS records are fully configured, the final step is to update your nameservers at your registrar. The exact steps depend on your registrar but generally follow this pattern:

1. 1Log in to your domain registrar's control panel.
2. 2Navigate to your domain's management page.
3. 3Find the Nameservers or DNS section.
4. 4Switch from the default nameservers to custom nameservers.
5. 5Enter ns1.rwa-host.rw and ns2.rwa-host.rw.
6. 6Save the changes.

After saving, use the Check nameservers button on the domain detail page to confirm that RHost can see the NS change. Propagation typically takes between 30 seconds and 48 hours depending on your registrar and the TTL of your previous NS records.

Expiry alerts#

RHost can notify you before a domain expires so you can take action in time. To configure alerts:

1. Open a domain's detail page.
2. Click Expiry alerts in the header.
3. Choose which days before expiry you want to be alerted (e.g. 90, 30, 7, 1 days).
4. Toggle email and in-app notifications on or off independently.
5. Use the Send test email button to verify delivery.

DNS Records#

Record types reference#

RHost supports all standard DNS record types. Below is a reference of the most commonly used ones:

Creating records#

Navigate to a domain's DNS Records tab and click Add record. Fill in the record modal:

• TypeSelect the DNS record type from the dropdown.
• NameThe hostname. Use @ for the zone apex (root domain), or enter a relative label like www, mail, _dmarc. RHost will automatically append the domain name.
• ValueThe record's content. For A records this is an IPv4 address; for CNAME it is the target hostname ending with a dot; for MX it is the mail server hostname.
• TTLTime To Live in seconds. Controls how long resolvers cache this record. Default is 300 seconds. Lower values allow faster changes but increase DNS query load.
• PriorityOnly visible for MX and SRV records. Lower numbers have higher priority.

Editing and deleting records#

Hover over any record row in the DNS tab and click the edit (pencil) icon to modify it, or the delete (trash) icon to remove it.

SOA and NS records are locked and cannot be edited or deleted. These records are managed by RHost to ensure zone integrity.

Pending vs active records#

When RHost auto-imports records from your existing DNS provider, they are created as pending. Pending records are stored in the database but are disabled in PowerDNS — resolvers will not serve them until you confirm.

This gives you the opportunity to review the imported records before they go live. In the DNS Records tab:

• Pending records are shown with an amber Pending badge.
• Click Confirm All to activate all pending records at once.
• Or select individual records and confirm them one at a time.
• Once confirmed, records are immediately served by PowerDNS.

History and rollback#

Every create, update, and delete action on DNS records is logged in the domain's History tab. Each entry shows:

• The action type (created, updated, deleted).
• The record type and name.
• The old and new values (for updates).
• The email address of the user who made the change.
• A timestamp.

Click Rollback on any history entry to instantly revert that record to its previous state. Rollbacks are themselves logged in the history.

Zone Management#

Importing a zone file#

RHost supports importing BIND-format zone files (.zone files). This is useful when migrating from another DNS provider that can export zone files.

Navigate to the Import / Export tab and paste or upload your zone file. RHost will:

• Validate the zone file format (must include SOA and at least two NS records).
• Delete existing non-locked records of the same types found in the import.
• Stage all parsed records as pending (disabled) for your review.
• Leave SOA and NS records untouched (they are locked).

After the import, go to the DNS Records tab and click Confirm All to activate the imported records.

A valid BIND zone file looks like this:

$ORIGIN example.rw.
$TTL 300

; SOA
@  IN  SOA  ns1.rwa-host.rw. hostmaster.example.rw. (
            2024010101 ; serial
            10800      ; refresh
            3600       ; retry
            604800     ; expire
            300 )      ; minimum TTL

; Nameservers
@  IN  NS   ns1.rwa-host.rw.
@  IN  NS   ns2.rwa-host.rw.

; A records
@     IN  A    192.168.1.1
www   IN  A    192.168.1.1
mail  IN  A    192.168.1.2

; MX record
@  IN  MX  10  mail.example.rw.

; TXT record (SPF)
@  IN  TXT  "v=spf1 ip4:192.168.1.0/24 ~all"

Exporting a zone file#

To export your zone as a BIND-format file, navigate to Import / Export and click Export zone file. The exported file contains all active records for the zone and can be imported into any BIND-compatible DNS server.

Zone file editor#

For advanced users, RHost provides a full zone file text editor. Navigate to Import / Export → Open zone editor. You can edit the raw zone file directly and save — changes are parsed and staged as pending records, following the same import flow.

DNSSEC#

What is DNSSEC?#

DNSSEC (DNS Security Extensions) is a suite of specifications that adds cryptographic authentication to DNS responses. Without DNSSEC, an attacker who can intercept DNS traffic could forge responses and redirect your visitors to malicious servers — a technique called DNS cache poisoning.

When DNSSEC is enabled, each DNS response includes a digital signature. Validating resolvers check this signature against a chain of trust anchored at the root DNS zone. If the signature does not match, the resolver discards the response and the domain is unreachable from that resolver.

Enabling DNSSEC#

Navigate to the DNSSEC tab on your domain's detail page and click Enable DNSSEC. RHost will:

• Generate a KSK (Key Signing Key) using ECDSA P-256 SHA-256 (algorithm 13) — the recommended modern algorithm.
• Sign all records in the zone.
• Provide you with DS (Delegation Signer) records to add at your registrar.

DS records#

After enabling DNSSEC, the DS records panel will display the DS record(s) you need to add at your registrar. They look like this:

12345 13 2 ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890

The fields are: Key Tag, Algorithm (13 = ECDSA P-256), Digest Type (2 = SHA-256), and the Digest itself.

Copy these values into your registrar's DNSSEC DS record configuration. Once the parent zone (e.g. the .com registry) publishes the DS record, the chain of trust is complete.

Apps#

What an app is#

An app is a container RHost runs for you and keeps running. It can come from a Git repository, which RHost builds for you, or from a container image you already have. There are four kinds: a web service that answers on a URL, a private service reachable only by your other apps, a worker with no URL at all, and a cron job that runs on a schedule instead of staying up.

Creating one#

Go to Apps → New. The form asks four things in order: what you are building, where the code is, how to configure it, and what to call it. Connect a Git provider the first time and RHost remembers it.

If your code lives in a subfolder of a larger repository, set Root directory to that folder — for example apps/api. Leave it as . to build from the repository root.

After the first build, the app's settings tell you what RHost recognised and how it built it. There is nothing to configure for this: if your repository has a Dockerfile it is used exactly as written, and if it does not, RHost detects the framework and builds it for you.

Domains and ports#

Every web app gets a free address straight away. To use your own, add it under Settings → Domains: RHost checks whether the domain is one it already manages, and if it is, offers to add the DNS record for you. If it is not, you are shown the exact record to add at your own provider, and RHost watches for it to appear.

Port is the port your app listens on inside its container — not the port visitors use. Get this wrong and the edge cannot reach your app: you will see a 502 or 503, and the message names the port it tried.

That preview is a real screenshot of whatever your address serves, retaken after each deploy and refreshed in the background. When there is no picture, the panel says why rather than sitting empty — the address has nothing serving yet, it answers with an error, or it serves an API rather than a page. An API having no preview is the correct outcome, not a fault.

Environment variables#

Set them under Settings → Environment. Changing one redeploys the app, because a running container cannot be handed new values. Variables marked available during build are also passed to the build step, which is what you want for anything a bundler reads.

Deploys#

Deploy history#

The Deployments tab lists every attempt, newest first, numbered from the first one. Each row shows whether it succeeded, the commit it built, when it ran and how long it took — which is the quickest way to notice a build getting slower.

Redeploy and roll back#

Redeploy builds the app again from wherever it comes from now, and is offered on the newest deployment. Roll back puts an earlier image back and is offered on previous successful deploys, for as long as the server still holds them — the last five.

Auto-deploy#

On by default for Git apps: pushing to the tracked branch deploys it. Turn it off, or switch branches, under Settings → Build & deploy.

In a monorepo, an app with a Root directory set skips a push that changed nothing under that folder — no filter needed. Build filters handle the rest: one glob per line, and a push whose every changed file matches is skipped.

Running migrations before a deploy#

A pre-deploy command runs before each new version goes live — usually database migrations. If it fails, the deploy stops and the running version is left alone, so a bad migration cannot take your app down. When RHost spots migrations in your repository it offers the command as one click.

It can run inside your built image, or from a fresh checkout of your source. Choose source when your production image does not ship the migration tool.

Events and logs#

Events is the app's own history — deploys, domain changes, scaling, restarts — with the full detail of any one of them a click away. Logs is your container's output, searchable and filterable by level, and you can look back over a window rather than only forward from now.

Databases#

Creating a database#

RHost runs managed PostgreSQL, MySQL and Redis. Pick an engine and a size; you can change the size later.

Connecting to it#

Each database shows two host names. The internal one is how your other apps reach it, and it never leaves RHost's network — use this one wherever you can. The public one is for connecting from your own machine, and only exists while external access is on.

Who can connect#

A database that is public on your own server accepts connections from anywhere until you say otherwise, and only the password stands in the way. Add the addresses that need it under Who can connect — one IPv4 address or range per line — and everything else is refused by the firewall before it can try a password. Apps on the same server always keep their access.

Importing a dump#

Upload a .sql, .sql.gz or PostgreSQL .dump file and RHost restores it. The file is deleted from our server as soon as the import ends, and you are told when it finishes — it runs for minutes, so you do not have to sit and watch it.

pgAdmin, PgHero and phpMyAdmin#

Each database offers one-click admin tools — pgAdmin and PgHero for PostgreSQL, phpMyAdmin for MySQL, Redis Commander for Redis. They deploy as ordinary apps already pointed at the database, with their sign-in details shown on the card. Remove one like any other app when you are done with it.

Static Sites#

Building from Git#

A static site is built from your repository and then served as plain files — no runtime, nothing to keep alive. Give RHost the repository, a build command if it needs one, and where the build output lands.

The publish directory#

This is the folder your build writes into — dist, build and out are the usual ones. A build that produces nothing servable fails loudly rather than publishing an empty site.

Your Own Server#

Bring your own server#

You can point RHost at a server you already own and deploy to it with the same console — the same apps, databases, domains, logs and deploy history, running on your hardware instead of ours.

Connecting a server#

Go to Servers → Connect a server and run the one-line install command it gives you. It installs a small agent that dials out to RHost — you do not need to open any inbound port or hand over SSH keys. The server appears in the console once the agent connects.

What you can run on it#

Everything you can run on RHost's own platform: web apps, private services, workers, cron jobs and databases. Apps on the same server reach each other by container name, and a database can expose an extra port to the outside world when you need it.

Projects#

Projects and environments#

A project groups the things that belong together, and each project has environments — Production to begin with, and whatever else you add. Anything that is not in a project yet shows up under Apps, where you can file it without redeploying.

Shared variables#

An environment group is a set of variables several apps share. Attach one, and its values fill in anywhere the app does not already define the same key — the app's own variables always win. Changing a group redeploys every app attached to it, so the change actually takes effect.

Command Line#

Everything described above happens in the console. The same things happen from a terminal with the RHost CLI, which is faster once you know what you want — and is the only way to deploy from a script, a Makefile or a CI job.

Installing it#

The CLI is an npm package with no runtime dependencies. It runs anywhere Node 20.11 or newer runs — macOS, Linux, Windows, WSL and inside a container — and there is nothing else to install alongside it.

npm  install -g @rhost-rw/cli
pnpm add -g @rhost-rw/cli
yarn global add @rhost-rw/cli
bun  add -g @rhost-rw/cli

rhost --version

You do not have to install it at all. This runs the current version and leaves nothing behind, which is what CI should use and the quickest way to try it:

npx -y @rhost-rw/cli deploy        # npm
pnpm dlx @rhost-rw/cli deploy      # pnpm
bunx @rhost-rw/cli deploy          # bun

If you do not have Node yet:

On Windows the CLI works the same in PowerShell, Command Prompt and Windows Terminal. The CLI checks the Node version itself and refuses to start on one too old, rather than failing later with a syntax error that explains nothing.

Signing in#

rhost login

It prints a link and opens it. Approve it in the browser — where you are already signed in, however you normally sign in — and the terminal signs itself in. Nothing is typed at the prompt, so no password goes into a terminal that is shared, recorded or scrolled back through, and an account that signs in with a passkey or with Google works the same as any other.

The terminal prints a one-time code and the page asks for it. The code is never in the link — a link that carried it could be sent to you, and one click would sign somebody else's terminal in as you. Typing it is what proves the terminal is yours. It expires after ten minutes.

The session is written to ~/.rhost/config.json, readable only by you. It is a real session: it appears under Settings → Security → Sessions alongside your browsers, and you end it from there.

Linking a directory#

Run this once inside your repository and you stop naming the app in every command:

cd my-api
rhost link

It writes .rhost.json next to your code. Commit it — it holds no secrets, and it means anyone who clones the repository can run rhost logs without looking anything up.

Creating apps and databases#

rhost create asks the same questions the New app wizard asks — what you are building, where the code is, which server, which port, which address — and then builds it.

rhost create                 # asks what to make, then asks for what it needs
rhost create app api         # web service, private service, worker, cron job, static
rhost create db orders       # Postgres, MySQL or Redis
rhost create site marketing  # a static site built from Git
rhost create project Acme
rhost create env Staging --project Acme

Everything it asks can be a flag instead, which is what makes it scriptable:

rhost create app api \
  --server edge-1 --kind web \
  --repo https://github.com/acme/api --branch main --port 3000 \
  --env NODE_ENV=production --env-file .env.production \
  --project Acme --environment Production --link

Kind is web, private, worker, cron or static, the same five as the console. Only web and private take a port; only cron takes a schedule.

The address works exactly as it does in the console. Leave --domain out and the app gets a free address under RHost's own domain, live immediately. Give a domain you own and the app waits until an A record points at the server — the CLI prints the exact record, and offers to add it for you when the zone is one RHost already serves.

Projects can be set as the app is created, with --project and --environment, or afterwards with rhost move. A project and an environment always travel together — both, or neither.

Deploying and reading logs#

rhost deploy              # build and release, following the build
rhost logs -f             # follow the running container
rhost logs --since 2h     # a window in the past
rhost logs --build        # the last build's transcript
rhost deployments         # history, newest first
rhost rollback            # put the last good deploy back
rhost status              # state, address, last deploy

rhost deploy prints the build as it happens and exits with a non-zero status if the deploy fails, so the same command works unchanged as a CI step. Piped or redirected, it starts the deploy and returns instead of following it.

Environment variables#

rhost env                                  # names, values masked
rhost env --reveal                         # values too
rhost env set DATABASE_URL=postgres://...
rhost env rm OLD_FLAG
rhost env pull .env.production

Setting or removing a variable redeploys the app, for the same reason it does in the console: a running container cannot be handed new values. The CLI reads the current set and merges your change into it, so setting one variable never drops the others.

Deploying from CI#

A CI job has no password to type, so it carries a token instead. Generate one on your own machine, then store it as a CI secret:

rhost token --reveal

- name: Deploy to RHost
  env:
    RHOST_TOKEN: ${{ secrets.RHOST_TOKEN }}
    RHOST_WORKSPACE: Acme Ltd
  run: npx -y @rhost-rw/cli deploy --follow

Every listing command takes --json, so scripts read structured output instead of parsing a table:

rhost apps --json | jq -r '.[] | select(.status=="failed") | .name'

Help inside the CLI#

This page is the tour. The CLI carries its own reference, so you do not have to come back here for a flag:

rhost help                 # every command, grouped, one line each
rhost help deploy          # one command in full: what it does, flags, examples
rhost deploy --help        # the same page, asked the other way round

rhost help install         # installing, per platform
rhost help ci              # tokens and pipelines
rhost help mcp-setup       # connecting an AI agent
rhost help environment     # every environment variable it reads

Each command's page says what the command does to the system, lists every option, shows worked examples and points at the commands you are likely to reach for next. The index is generated from those pages, so a command can never be listed with one description and explained with another.

Command reference#

rhost help <command> prints any one of these in full — every flag, with examples.

AI Agents#

What the MCP server is#

The CLI package also ships an MCP server. MCP — the Model Context Protocol — is how an AI coding agent is given tools it can call. Point one at RHost and it can read your deploy history, pull a failing build log, check which environment variable is missing, and put the last good version back, without you copying anything between a browser and a chat window.

It reuses the session rhost login already created, so there is no second credential to manage.

Connecting your agent#

Add RHost to your agent's MCP configuration:

{
  "mcpServers": {
    "rhost": {
      "command": "npx",
      "args": ["-y", "@rhost-rw/cli", "mcp"],
      "env": { "RHOST_WORKSPACE": "Acme Ltd" }
    }
  }
}

The configuration is the same everywhere; only the file it goes in changes:

Any client that speaks MCP over stdio works the same way, on any platform — the server is the same npm package, started by npx, so nothing extra is installed. In an environment with no interactive login — a container, a hosted agent — add RHOST_TOKEN to the env block instead of signing in. rhost help mcp-setup prints all of this in the terminal.

What it can do#

Twenty-five tools, split between reading, creating and changing things:

• Reading — the workspace overview, the app list, one app's status, runtime and build logs, deploy history, the event timeline, environment variable names, databases, servers, domains and DNS records.
• Creating — an app or database on one of your servers, a static site, a project or an environment, and filing an existing app under one.
• Changing — deploy, roll back, set or remove environment variables, stop or start an app, run a one-off command such as a migration, and add a DNS record.
• Explaining — a built-in guide to how RHost deploys work, so the agent diagnoses from the platform's actual behaviour rather than guessing at it.

Limits and safety#

An agent is given less than you have, on purpose:

• Secrets are masked. Environment values come back as lengths, and database connection details are refused outright, unless the server is started with RHOST_MCP_ALLOW_SECRETS=1.
• RHOST_MCP_READ_ONLY=1 removes every writing tool from the list, so the agent cannot deploy or change a variable even if it decides to.
• Nothing destructive is offered at all. No tool deletes an app, a database, a domain or a record — those stay in the console, behind a person.

API#

Base URL and authentication#

The console is built on a REST API you can call yourself, at https://rhost.rw/api. Requests carry a bearer token:

# 1. exchange credentials for a session
curl -s https://rhost.rw/api/auth/login \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.rw","password":"..."}'
# -> { "accessToken": "...", "refreshToken": "...", "user": { ... } }

# 2. call anything with the access token
curl -s https://rhost.rw/api/auth/me \
  -H "authorization: Bearer $ACCESS_TOKEN"

Access tokens are short-lived. Keep the refresh token and exchange it for a new access token at POST /auth/refresh when a call returns 401. If the account has two-factor sign-in, the login call answers with requiresMfa and a challenge token to complete at POST /auth/login/mfa-verify.

Workspace scope#

Almost everything outside /auth is scoped to a workspace, passed as a query parameter rather than inferred from your account — an account can belong to several, and the API will not guess which one you meant.

curl -s "https://rhost.rw/api/workspaces" -H "authorization: Bearer $ACCESS_TOKEN"
# -> [{ "id": "8f2c...", "name": "Acme Ltd" }]

curl -s "https://rhost.rw/api/compute/nodes/apps?workspaceId=8f2c..." \
  -H "authorization: Bearer $ACCESS_TOKEN"

Apps live under two route families, because an app runs either on RHost's own platform or on a server you registered: /compute/apps for the first, /compute/nodes/:serverId/apps for the second. Static sites are a third, at /static-sites. The CLI hides this; a direct caller has to pick the right one.

A worked example#

Deploying an app on your own server, and watching it, is two calls:

BASE=https://rhost.rw/api
AUTH="authorization: Bearer $ACCESS_TOKEN"

# start the deploy
curl -s -X POST "$BASE/compute/nodes/$SERVER/apps/$APP/redeploy?workspaceId=$WS" -H "$AUTH"

# follow it: phase is queued -> cloning -> building -> starting -> routing -> live
curl -s "$BASE/compute/nodes/$SERVER/apps/$APP/deploy-progress?workspaceId=$WS" -H "$AUTH"
# -> { "phase": "building", "lines": ["...", "..."] }

Errors come back as JSON with a message written for a person — a single string, or an array of them when a request failed validation. Read it before retrying; most 400s name the field.

Account Security#

Two-factor authentication#

A second step after your password, set up under Settings → Security. There are three to choose from, and one is active at a time: a passkey, an authenticator app, or a code emailed to you. Setting up a new one replaces the previous.

Passkeys#

The strongest of the three, and the least work: your fingerprint, your face, or a security key. There is no code to type and nothing that can be phished, because the secret never leaves your device.

Authenticator apps#

Scan the QR code with any authenticator app and enter the six-digit code it shows. The codes rotate every thirty seconds and work with no signal and no network.

Backup codes#

Setting up an authenticator gives you ten backup codes. Each works once, in place of a code from the app, and they are shown exactly once — save them somewhere that is not the phone holding the authenticator. You can issue a fresh set at any time, which invalidates the old one.

Billing & Payments#

How pricing works#

RHost only charges for what you switch on. There are a few kinds of charge:

• Domains — a yearly fee to register, or a smaller yearly fee to host DNS for a domain you registered elsewhere.
• Apps — a flat monthly price for the size you chose, paid per app. Stopping an app does not stop its charge; removing it does.
• Databases — the same, priced by engine and size.
• Static sites — free to host. You pay only for the domain they answer on.
• Your own servers — nothing. RHost charges for what it runs on its hardware, not for what it deploys onto yours.

If a promotion is running, the discount is shown right on the price (with the original struck through) and applied automatically at checkout.

Paying (checkout)#

All payments go through a secure checkout. You're redirected to enter your card details, and as soon as the payment succeeds RHost activates the service and brings you back to the dashboard. You never enter card numbers directly into RHost.

Invoices & payment method#

The Billing page in the console lists your active services as a single tidy summary — the Workspace on one line, each add-on on its own — plus your total monthly cost. Your invoices appear there too, each with a downloadable PDF. Click Manage payment method to update your card or review past payments in the secure billing portal.

Cancelling a service#

You cancel a service by removing the thing it pays for: delete the app, the database or the site, and the charge stops at the end of the term you already paid. A domain stops renewing when you turn auto-renew off on its page, and keeps working until it expires.

Team & Members#

Your account & team#

Your account is the home for everything you own — your domains, DNS zones, billing, and the teammates who help you manage them. It's created automatically when you sign up; there's nothing to configure.

Inviting members#

To invite a team member to a workspace:

1. 1Navigate to Settings → Workspace in the console.
2. 2Click Invite member and enter their email address.
3. 3Select their role (Owner, Admin, or Member).
4. 4Click Send invitation.

The invitee will receive an email with a link to accept the invitation. They must have an RHost account (or create one) before the invitation can be accepted.

Frequently Asked Questions#

How long does DNS propagation take?#

Propagation time depends on two things: the TTL of the record being changed, and how aggressively resolvers respect TTLs. In practice:

• Records with a TTL of 300 seconds (5 min) typically propagate globally within 5–15 minutes.
• Records with a TTL of 86400 seconds (24 hours) can take up to 48 hours to propagate fully.
• Nameserver changes (NS records) are typically slower — allow up to 48 hours even with a low TTL.

The nameservers are not pointing — what should I do?#

If the Check nameservers button still shows "Nameservers not pointed" after waiting for propagation:

• Double-check that you saved the nameserver change at your registrar. Log back in and confirm ns1.rwa-host.rw and ns2.rwa-host.rw are listed — both end in .rw.
• Some registrars require nameservers to be registered (glue records) before they can be used. RHost nameservers are already registered — no glue records needed.
• Wait the full 48 hours. Propagation for NS changes is legitimately slow with some registrars.
• Query the NS record from several resolvers at once with the propagation checker under Tools, and compare what each one returns.

I confirmed my records but they are not resolving#

If your records are confirmed (active, not pending) but queries are still not resolving as expected:

• Verify that your domain's nameservers are pointing to RHost (check the Live badge on the domain overview).
• Ensure the record type and name are correct. Use the DNS Lookup tool to query your domain directly.
• Check that you do not have a conflicting CNAME at the zone apex — CNAME records cannot coexist with other record types at the same name.
• If you recently added the record, allow a few seconds for it to propagate through the packet cache.

Should I enable DNSSEC?#

Yes, if your registrar supports DS record management (most modern registrars do). DNSSEC adds a meaningful layer of security against DNS spoofing and cache poisoning attacks with minimal performance overhead.

The main caveat is that once you enable DNSSEC and add DS records at your registrar, you must not disable DNSSEC or delete the zone in RHost without first removing the DS records from your registrar. Leaving orphaned DS records at the registrar will cause DNSSEC validation to fail and make your domain unreachable from validating resolvers.

My deploy succeeded but the address returns 502 or 503#

A successful deploy means the container started, not that anything is listening where RHost is routing. Two causes account for nearly all of these:

• The port is wrong. Port is the port your process listens on inside the container, not the port visitors use. The error message names the port RHost tried — compare it with what your app logs at startup.
• The process is bound to 127.0.0.1. Inside a container that means nothing outside it can connect. Bind 0.0.0.0 instead; most frameworks take a host flag or a HOST environment variable.

Runtime logs tell you which it is — the build log will not, because the build worked.

Can I deploy without opening the console?#

Yes. Three ways, depending on who is doing the deploying:

• You, from a terminal — the CLI. Install it, run rhost link once in your repository, and rhost deploy from then on.
• A push — auto-deploy. On by default for Git apps: push to the tracked branch and it deploys, with build filters to skip pushes that changed nothing relevant.
• A pipeline — the CLI with a token. Store RHOST_TOKEN as a CI secret and run npx -y @rhost-rw/cli deploy; it exits non-zero when the deploy fails, so the job fails with it.

An AI coding agent can do the same through the MCP server, which is the same package.