# Linux server: HTTPS, service and operations

> Install an authorised package, configure HTTPS, complete first-run setup and verify a real company process.

_Updated: 2026-10-09_

This guide covers a customer-managed Linux server. Obtain the exact supported
release from your railbase.app Account. Availability in Account determines which
package and architecture you can install; a development demo or CI candidate is
not a customer release.

For a Mac, start with the signed installer in the [installation guide](/en/learn/installation).
Hosting on your own VPS is On-premise/customer-hosted deployment. Railbase Cloud is also available by invitation for hosting operated by Railbase. See [deployment choices](/en/learn/deployment) or open [Cloud in Account](/account/cloud).

## 1. Obtain the package through Account

Sign in to railbase.app, complete company verification and review the Railbase
Product subscription. In Account, use the available installation package or the
[authenticated Linux repository](/en/learn/linux-package-repository). Each repository
credential belongs to a specific authorised account and can be revoked.

After applying the repository setup commands supplied by Account:

```bash
# Debian / Ubuntu
sudo apt update
sudo apt install railbase
```

```bash
# Fedora / RHEL-compatible systems
sudo dnf install railbase
```

Use the architecture shown for your server. Keep package and repository signature
verification enabled. Do not obtain the runtime from an unverified mirror or a
public demo server.

## 2. Check the installed service and its state

The Linux package creates the `railbase` service account and installs the service,
configuration and initial private unlock material. Its default listener is
`127.0.0.1:3000`.

```bash
railbase --version
sudo systemctl status railbase
curl --fail http://127.0.0.1:3000/healthz
curl --fail http://127.0.0.1:3000/readyz
```

| Purpose | Packaged Linux location |
| --- | --- |
| Service configuration | `/etc/railbase/railbase.env` |
| Vault unlock file | `/etc/railbase/vault-password` |
| Data, uploaded files and runtime state | `/var/lib/railbase` |
| Installation master secret | `/var/lib/railbase/.secret` |
| Active runtime managed by the update lifecycle | `/var/lib/railbase/runtime/railbase` |

On a fresh packaged installation, the installer creates independent secrets. If
an existing Vault is present and a required secret is missing, restore the
matching secret from backup; generating a replacement will not recover the data.
Do not replace the package service with a second service pointing at another data
folder.

## 3. Configure the public HTTPS address

Point your chosen hostname at the server. Keep Railbase bound to loopback and
allow public access through a reverse proxy on HTTPS. For Caddy:

```text
app.example.com {
    reverse_proxy 127.0.0.1:3000
}
```

Set the public origin in the existing protected service environment file:

```ini
RAILBASE_PROD=true
RAILBASE_DEV=false
RAILBASE_HTTP_ADDR=127.0.0.1:3000
RAILBASE_DATA_DIR=/var/lib/railbase
RAILBASE_VAULT_PASSWORD_FILE=/etc/railbase/vault-password
RAILBASE_PUBLIC_URL=https://app.example.com
RAILBASE_TRUSTED_PROXIES=127.0.0.1/32,::1/128
RAILBASE_ENCRYPT_STORAGE=true
```

Keep any other intentional settings already in that file. Then restart the
service and check readiness again:

```bash
sudo systemctl restart railbase
curl --fail https://app.example.com/healthz
curl --fail https://app.example.com/readyz
```

`RAILBASE_PUBLIC_URL` must be the origin users can actually reach, including a
valid certificate. Invitation links and mobile authentication depend on it.
Trust only the actual reverse-proxy addresses. If you use another proxy, preserve
Host and forwarded protocol information and support both streaming responses and
WebSocket upgrades.

Uploaded files are encrypted by default; keep encryption enabled. The Vault
password and installation master secret are different recovery requirements.
Protect and back up both; neither belongs in a chat, screenshot or public script.

## 4. Complete the browser first-run setup

Follow [first browser setup](/en/learn/installation#first-browser-setup), then [company setup](/en/learn/core-company-setup). Keep access limited to the installation operator until setup is complete. Installation authority and company membership remain separate.

## 5. Connect the Product and prove the first result

Connect the deployment through the supported Account/installation flow and verify
that the intended company has the active Railbase Product entitlement. Only
install additional Products that are available for that account and release.

Invite the requester and reviewer, publish the required organisation and process,
and complete the [first-process walkthrough](/en/learn/core-first-process). Check the request,
attachment, decision and final dossier using each person's actual role. A running
service and an HTTP 200 do not establish that the business workflow is ready.

For Mobile, open **Connect phone** on the installation sign-in page and scan the
QR from a second screen. Confirm the HTTPS origin, then sign in as an existing
invited user. Company choices come from that authenticated identity. A localhost
address reachable on the server is not necessarily reachable from a phone.

## 6. Preserve recovery and update evidence

Back up `/etc/railbase` and the complete configured state under `/var/lib/railbase`,
including matching secrets and external file stores where configured. Use the
[backup and recovery guidance](/en/learn/backups-and-restore) and verify recovery
in an isolated installation. Copying a running Vault alone is not a complete
recovery test.

Use the authenticated, verified update channel and your maintenance policy. Keep
the deployed version, previous recoverable state and support contacts recorded.
If startup fails, inspect `sudo journalctl -u railbase` and the actual configuration;
do not work around it by enabling DEV or replacing a missing secret.

## Operating ownership and support

Your company or appointed operator owns server access, networking, storage, patching, backups and recovery. Managed services, response targets and recovery commitments apply only where explicitly ordered. Infrastructure, external AI usage, industry Suites and additional services are separate from the company subscription; see [pricing and full cost](/en/learn/pricing-and-capacity).

For Railbase Cloud, Railbase operates hosting, updates and backups under the accepted [Cloud service terms](/en/legal/cloud). The invitation-only standard offer uses the [company Product price](/en/learn/pricing-and-capacity) before applicable tax, including 1 GB of company data. Request Cloud in [Account](/account/cloud) when offered; activation follows company verification, subscription and installation checks.

Before an update, review dependencies, process revisions and published Studio configuration. Preserve a recoverable state and follow the supported migration path. Review [offline licence conditions](/en/learn/trust-licenses-and-offline-use); self-hosting does not imply perpetual disconnected licensing.

For support, supply versions, a reference to the failed step and sanitised diagnostics through the agreed channel. Server administration does not grant automatic access to company business content. Existing invoices and accepted commercial terms remain historical evidence.

## About the shared demo

A public Railbase demonstration may deliberately run in DEV mode with synthetic
people and role switching. That environment helps you explore workflows. It does
not establish customer release acceptance, host your company data or provide a
production configuration to copy.