Detached servers

Detaching hands a server back to you without stopping its current applications and services. strackt creates a plain, standalone configuration under /etc/nixos/, applies it, and checks the handoff account, public key, resulting system, and essential services before the dashboard marks the server as Self-managed.

If one of those checks fails, the handover stops and the server remains managed by strackt. The operation explains what happened so you can correct it and try again.

After a successful handover, the server page shows its detached state, connection command, backup details, applications, retained strackt access, and handover guide. The guide is also sent to the person who started the handover and the workspace owner.

strackt can confirm that your public key was installed, but it does not have your private key. Test the SSH command from the handover guide from a device that holds the matching private key.

What keeps working

• Your applications keep serving traffic, and their workers and scheduled tasks keep running.
• Databases and other services on the server keep running.
• Custom domains stay configured. Their TLS certificates keep renewing while DNS points to this server and ports 80 and 443 remain reachable.
• Backups to your own S3-compatible bucket keep their saved schedule. A daily backup remains daily when that was the schedule active at handover.
• On servers using ZFS, local snapshots continue to be created and pruned on the server.

What stops

• strackt no longer monitors, patches, or maintains the server. It also no longer watches detached backup jobs or alerts you when one fails.
• strackt-provided *.on-strackt.dev URLs stop working. Connect a custom domain before detaching if a site still depends on one of these URLs.
• Deploys from the strackt dashboard stop. You manage application releases and restarts directly on the server.
• Server-to-server offsite snapshot replication through strackt stops. Backups to your own S3-compatible bucket are separate and can continue as described above.

Edit your configuration

Everything needed to rebuild the server lives under /etc/nixos/. Edit the files that own the setting you want to change:

• configuration.nix contains server-wide settings such as users, SSH, networking, firewall rules, packages, and imports.
• hardware-configuration.nix describes the server's disks, filesystems, and boot setup. Leave it unchanged unless the underlying hardware or disk layout changes.
• apps/ contains one file for each application environment, including its runtime, paths, domains, workers, scheduled tasks, and cloud backup job.
• services/ contains one file for each database, cache, or other server-level service, including any cloud backup job for that service.
• flake.nix identifies the software source used to rebuild this server. You normally do not need to edit it.

Apply your edits with:

sudo nixos-rebuild switch --flake path:/etc/nixos#<host>

Replace <host> with the server identifier shown in your handover guide. The first rebuild after detach is slower because it fetches software from the public cache.nixos.org cache. Later rebuilds can reuse files already stored on the server.

If a change prevents the new configuration from starting correctly, return to the previous system generation with:

sudo nixos-rebuild switch --rollback

Manage backups after detach

The detached-server page and handover guide show each carried-over backup's bucket, schedule, and timer name. The root-only credentials file is:

/var/lib/strackt-backup/credentials.env

That file contains the bucket access values and the password that encrypts and unlocks the backups. Keep the existing encryption password when continuing to use the same backup repository; replacing it makes the existing backups unreadable with the new password. Keep the file owned by root, mode 0600, and do not share its contents.

Use the timer name from your handover guide to inspect a backup and its latest log:

sudo systemctl status strackt-backup-<backup-id>.timer
sudo journalctl -u strackt-backup-<backup-id>.service

To stop one immediately:

sudo systemctl disable --now strackt-backup-<backup-id>.timer

A later rebuild can enable that timer again while its definition remains in the configuration. To stop it permanently, also remove the matching timer and service definitions from the relevant file under /etc/nixos/apps/ or /etc/nixos/services/, then rebuild.

To send a backup to a different bucket, update the repository settings in the matching application or service file, replace the bucket access values in the root-only credentials file, and rebuild. Change the encryption password only when you intentionally want a new backup repository. Afterward, start the timer and check its service log yourself; strackt no longer monitors the result.

If the handover guide says the backup credentials are missing, the schedules were preserved but the backup jobs cannot connect to the bucket. Restore the root-only credentials file before relying on those backups, or contact support for help.

Remove strackt access

The standalone configuration keeps one clearly marked access block so strackt can re-attach the server later. Remove it in two steps:

1. In /etc/nixos/configuration.nix, delete everything from the line beginning # --- strackt access through # --- end strackt access ---.
2. Apply the change:

sudo nixos-rebuild switch --flake path:/etc/nixos#<host>

This removes the strackt admin user, its stored SSH key, and its sudo access from the active configuration. The dashboard's re-attach action can no longer connect after this change.

Re-attach the server

The workspace owner can open the detached server in the dashboard and choose Re-attach server. The confirmation warns that strackt regenerates and applies its managed configuration, overwriting manual configuration changes made after detach.

When the marked strackt access block is still present, the dashboard action uses that retained access to start re-attachment. If you removed the block, re-adopt the server with its current SSH credentials instead.