strackt manages applications on servers you own. To do that, it needs a way in — to install updates, apply configuration, and deploy your code. This page explains exactly how that connection works, what strackt can and can't touch, and what happens when things go wrong.
The short version: strackt connects as a dedicated user over short-lived, signed credentials, records everything it does, and never sits between your users and your app. Your server stays yours.
How strackt connects
strackt reaches your server the same way you would — over SSH — but without long-lived keys or shared passwords lying around.
A dedicated
stracktuser is created on your server during setup. strackt does not log in asrootfor day-to-day work, and never uses your personal account.Access uses short-lived SSH certificates, signed on demand and valid for minutes, not months. There is no permanent private key on a laptop that, if leaked, hands over your server.
The control plane reaches your servers over an encrypted private network, so management traffic never crosses the public internet in the clear.
You can see how strackt reaches each server, and revoke its access at any time — it's your machine.
What access strackt needs
To manage a server, strackt needs administrative rights on it — the same rights you'd need to install a security patch or restart a service. The dedicated user has those rights, scoped to management tasks.
strackt uses that access to keep your server configured, patched, and running your application — not to mine your data. And every command it runs is recorded, so "trust us" is backed by a trail you can read.
What strackt stores — and what it never stores
strackt keeps the minimum it needs to manage your server, and keeps your application's data where it belongs: on your server.
What strackt stores
- Your server's address and how to reach it.
- The configuration that defines your server, kept as code.
- Short-lived access credentials and your application secrets — encrypted in a dedicated secrets vault, injected at deploy time.
- A history of the operations strackt has run for you.
What strackt never stores
- A copy of your application's database or user data — that lives only on your server.
- Long-lived root passwords or permanent SSH keys to your machine.
- Your application's traffic — strackt is not a proxy in front of your app.
What gets recorded
Every action strackt takes on your server is recorded — what ran, what triggered it, and how it turned out. Provisioning, deploys, patches, restarts, and rollbacks all leave a trail you can read in your dashboard, live as it happens.
If strackt changes your server, you can see that it did, when, and why.
Checkpoints and rollback
Changes to your server are built to be reversible.
Configuration changes are atomic. An update either applies completely or rolls back on its own. A half-applied server isn't a state strackt will leave you in.
Previous known-good states are kept. If a change causes trouble, strackt can roll the server back to the last working configuration in seconds.
Deploys are reversible too. Application releases are versioned, so returning to the previous release is fast and targeted.
Checkpoints you can restore. strackt keeps point-in-time checkpoints of your server, so a bad change or a mistake has a known state to return to.
Leaving strackt
You own the underlying server at your hosting provider the whole time strackt manages it. That does not change if you leave.
Stop using strackt and your server keeps running, with your application still on it. You keep full control of the machine — there is no platform to escape, because the infrastructure was always yours.
When something goes wrong
Managed doesn't mean magic. Here's what happens in the cases that matter.
A configuration change fails. strackt rolls the server back to its last working state automatically. You are notified, and your app keeps running on the previous configuration.
strackt is unavailable. Your application keeps serving traffic. strackt manages your server but isn't in the path between your users and your app, so an outage on our side doesn't take your site down.
strackt can't reach your server. It retries, and tells you if the server stays unreachable. It won't silently assume everything is fine.
Under the hood
For the curious, the connection model above rests on a few deliberate choices. Servers are defined declaratively with NixOS, so a server's state is code and every change is atomic. Access credentials and application secrets are issued and held by HashiCorp Vault — short-lived, never written to disk in the clear. The control plane reaches your servers over a Nebula encrypted mesh, so there are no public management ports to attack.
Want the bigger picture? Read how it works, or our security and disclosure policy.