Skip to main content

Operating the single-server install

Written by Aron Day

Day-to-day operations for a 3B single-server install: what the installer changed, how to manage and back up the stack, and how to remove it.

What the installer changes on your server

For transparency, here is what the install touches:

  • Creates /opt/3b and places the installer, the Helm chart (chart/), the bundled binaries (bundled/), configuration (.env), and the generated Helm values there.

  • Installs k3s, a single-node Kubernetes that runs as the k3s system service. Its data (the imported images and the database and file storage volumes) lives under /var/lib/rancher/k3s, and its admin config is written to /etc/rancher/k3s/k3s.yaml.

  • Installs binaries to /usr/local/bin: k3s, helm, and the oras registry tool. Missing base tools (curl, tar, unzip) are installed via your package manager.

  • Writes kernel settings to /etc/sysctl.d/99-3b-userns.conf to enable the user-namespace features the secure sandboxes need (only the settings your kernel exposes are written). On kernels older than 5.19 it also configures a containerd fallback for slower file-ownership changes.

  • Disables nm-cloud-setup (nm-cloud-setup.service and .timer) if present, because it conflicts with k3s networking.

  • Deploys 3B into the 3b Kubernetes namespace — the application secrets, a registry pull secret, an optional TLS secret, and the 3b Helm release.

  • Stores all generated secrets in /opt/3b/.env, which is locked down to root-only read/write (chmod 600), and also as Kubernetes secrets.

Keep /opt/3b/.env safe — it contains your encryption keys and database password.

Managing the stack

3B runs on the single-node Kubernetes the installer set up. Use the bundled k3s kubectl (and helm) to operate it, as root. Everything lives in the 3b namespace.

# See the status of every component
sudo k3s kubectl -n 3b get pods

# Follow logs for one service (e.g. api)
sudo k3s kubectl -n 3b logs deploy/api -f

# Restart a single service
sudo k3s kubectl -n 3b rollout restart deploy/api

# Stop everything (frees CPU and RAM; data is kept), then start it again
sudo systemctl stop k3s
sudo systemctl start k3s

To check the Helm release, or to apply a change you made in /opt/3b/.env (for example a new URL, SMTP, or a TLS certificate), re-run the installer rather than editing Kubernetes by hand — it regenerates the configuration and upgrades the release:

sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml /usr/local/bin/helm -n 3b status 3b   # inspect the release
sudo bash /opt/3b/setup.sh                                                      # apply config changes

Re-running and resuming a cancelled install

The installer is safe to run again. It reuses what is already configured:

  • Your answers and generated secrets are saved in /opt/3b/.env (and recovered from the Kubernetes secrets on an upgrade). On a re-run, the installer reuses them and only prompts for anything still missing.

  • If you stopped at the “Proceed?” confirmation, nothing was changed — edit /opt/3b/.env if you like, then re-run sudo bash /opt/3b/setup.sh.

  • To change a setting later, edit the relevant line in /opt/3b/.env and re-run setup.sh. See the configuration reference.

You do not need to re-run bootstrap.sh to re-run the install; once the bundle is in /opt/3b, sudo bash /opt/3b/setup.sh is enough.

Backing up and restoring

This single-server install has no automatic backups. If the data matters, back it up regularly and store the copies off the server. Three things make up a full backup:

  1. /opt/3b/.env — your configuration and all encryption keys (these are also held as Kubernetes secrets, but .env is the source of truth). This is critical: without these keys, the stored, encrypted credentials cannot be decrypted even if you still have the database. Keep this file as safe as a password vault.

  2. The Postgres database — your spaces, workflows, users, and run history.

  3. The file storage — attachments and the blob store (held in Kubernetes persistent volumes).

Back up

The database dump needs no downtime. The database runs in the postgres-0 pod.

cd /opt/3b
mkdir -p backup

# 1. Configuration and encryption keys
sudo cp .env "backup/env-$(date +%F).bak"

# 2. Database (logical dump)
sudo k3s kubectl -n 3b exec -i postgres-0 -- pg_dump -U postgres 3b \
  | gzip > "backup/db-$(date +%F).sql.gz"

For the file storage volumes, the underlying data lives under /var/lib/rancher/k3s/storage/. The simplest consistent copy is to stop the stack (sudo systemctl stop k3s), archive that directory (sudo tar czf backup/storage-$(date +%F).tar.gz -C /var/lib/rancher/k3s storage), then start it again.

Copy the backup/ directory to secure off-server storage.

Restore

Restore onto a clean install of the same VERSION and STACK_NAME:

  1. Put your backed-up .env in place at /opt/3b/.env, then run sudo bash /opt/3b/setup.sh to bring the stack up with the original keys.

  2. Restore the database:

gunzip -c backup/db-YYYY-MM-DD.sql.gz \
  | sudo k3s kubectl -n 3b exec -i postgres-0 -- psql -U postgres 3b

If you also archived the storage directory, restore it while k3s is stopped, then start k3s again.

Troubleshooting

Message or symptom

What it means and what to do

Run as root

You did not run as root. Re-run the command with sudo.

Linux only / amd64 hosts only

The server is not 64-bit (amd64) Linux. 3B requires an amd64 Linux server.

Linux kernel … does not support idmapped mounts … 5.12 or newer

The kernel is too old for k3s worker isolation. Upgrade the kernel (or use a newer OS image), then re-run. Check with uname -r.

curl is required / openssl is required / python3 is required

Install the named tool with your package manager (apt-get, dnf, or yum) and re-run.

Login to oci.tines.com failed

The tenant name or API key is wrong. Double-check both with Tines and re-run.

REGISTRY_USERNAME and REGISTRY_PASSWORD must be set when REGISTRY is set

A standard (online) install needs registry credentials. Provide them, or use the air-gapped bundle which ships the images.

LICENSE must be set

The signed 3B license token is missing. Set LICENSE=3bl_v1_… in /opt/3b/.env (or the environment) and re-run. See applying a license.

Install stops with Missing required values: … or … must be set in .env

You ran non-interactively without supplying everything. Set the listed values (in the environment or in /opt/3b/.env) and re-run.

Timed out waiting for … (k3s node, a deployment, or the migration job)

A component did not become ready in time. The installer prints the affected pods’ describe output and logs; inspect with sudo k3s kubectl -n 3b get pods and sudo k3s kubectl -n 3b logs deploy/<service>. Often a registry or network issue or insufficient resources — re-running is safe.

Browser warns the certificate is not trusted

Expected with a self-signed certificate. Trust it manually for evaluation, or switch to a real certificate (re-run and choose TLS option 2).

Cannot reach the UI in the browser

Confirm DNS points at the server, the firewall allows ports 80/443, and the nginx pod is Running.

The installer prints each step as it runs and, on failure, dumps the affected component’s status and logs, so the output just before it stopped usually points at the cause.

Getting help and support

If you are stuck, contact your Tines representative or support channel. To help them help you quickly, gather:

  • The release version you are installing (the VERSION line in /opt/3b/.env).

  • The operating system and kernel (uname -a and, if available, cat /etc/os-release).

  • The point of failure — the last lines the installer printed, and the status and logs of the affected service (sudo k3s kubectl -n 3b get pods and sudo k3s kubectl -n 3b logs deploy/<service>).

Redact secrets before sharing any output: never send the contents of /opt/3b/.env, your registry API key, or unredacted logs.

Uninstalling

To remove 3B and the single-node Kubernetes the installer created, run the k3s uninstaller (created during install):

sudo /usr/local/bin/k3s-uninstall.sh

This stops and removes k3s and all of its data, including 3B’s database and file storage — this permanently deletes all 3B data. Afterwards, remove the install directory and the kernel-settings file:

sudo rm -rf /opt/3b
sudo rm -f /etc/sysctl.d/99-3b-userns.conf

If you only want to remove the 3B application but keep k3s running, uninstall the Helm release instead:

sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml /usr/local/bin/helm -n 3b uninstall 3b
sudo k3s kubectl delete namespace 3b
Did this answer your question?