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/3band 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
k3ssystem 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 theorasregistry tool. Missing base tools (curl,tar,unzip) are installed via your package manager.Writes kernel settings to
/etc/sysctl.d/99-3b-userns.confto 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.serviceand.timer) if present, because it conflicts with k3s networking.Deploys 3B into the
3bKubernetes namespace — the application secrets, a registry pull secret, an optional TLS secret, and the3bHelm 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/.envif you like, then re-runsudo bash /opt/3b/setup.sh.To change a setting later, edit the relevant line in
/opt/3b/.envand re-runsetup.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:
/opt/3b/.env— your configuration and all encryption keys (these are also held as Kubernetes secrets, but.envis 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.The Postgres database — your spaces, workflows, users, and run history.
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:
Put your backed-up
.envin place at/opt/3b/.env, then runsudo bash /opt/3b/setup.shto bring the stack up with the original keys.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 |
| You did not run as root. Re-run the command with |
| The server is not 64-bit (amd64) Linux. 3B requires an amd64 Linux server. |
| The kernel is too old for k3s worker isolation. Upgrade the kernel (or use a newer OS image), then re-run. Check with |
| Install the named tool with your package manager ( |
| The tenant name or API key is wrong. Double-check both with Tines and re-run. |
| A standard (online) install needs registry credentials. Provide them, or use the air-gapped bundle which ships the images. |
| The signed 3B license token is missing. Set |
Install stops with | You ran non-interactively without supplying everything. Set the listed values (in the environment or in |
| A component did not become ready in time. The installer prints the affected pods’ describe output and logs; inspect with |
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 |
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
VERSIONline in/opt/3b/.env).The operating system and kernel (
uname -aand, 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 podsandsudo 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
