Most servers become mysteries. Someone changes a setting during an incident, installs a tool by hand, pins a package "just for now" — and nobody writes it down. Months later, no one's quite sure what's actually on the machine, or why.
strackt servers don't work that way. The whole server is defined in one place, that definition is the only thing that changes it, and every version the server has ever been is kept — so strackt can always put it back to a state you've already seen run.
Why servers become mysteries
Every server that runs long enough collects history. A fix here, a manual tweak there, a dependency someone bumped to put out a fire. None of it is wrong on its own. But it adds up to a machine whose real setup lives only inside the machine — and in the memory of whoever last touched it. When it needs rebuilding, or when a change goes wrong, there's nothing clean to go back to.
Your server is defined, not assembled
On a strackt server, the setup isn't a series of steps we ran once and hoped would stick. It's a single description of exactly how the server should be — every package, service, user, and firewall rule. strackt reads that description and makes the server match it. Change the description, and the server changes with it. Nothing changes the server any other way.
This is the difference between a server that was configured and one that is defined. A configured server is the sum of everything anyone ever did to it, in order — and the only record of that is the server itself. A defined server is the other way around: the definition is the source of truth, and the running server is just its current expression. If the two ever disagree, the definition wins on the next operation strackt runs. That's what keeps it a machine you can read, rather than one you have to investigate.
How a change actually lands
Every change to a strackt server takes the same path, whether it's a security patch, a new service, or a one-line setting. strackt never edits the running server in place — it builds a complete new version from the definition, then switches to it. Three things fall out of working that way:
Built before it switches. The new version is built alongside the one that's running, so a build that fails never reaches the server serving your users.
Switched in one step. There's no in-between moment where the server is half its old self and half its new one.
All or nothing. A change lands completely or not at all — the only two places strackt leaves you are on the new version, or on the one you had.
A security patch, step by step
Say a critical patch lands for a package running on your server. Here's the exact sequence — and where it stops if anything goes wrong:
Update the definition. strackt sets your server's definition to the patched version.
Build alongside. It builds a complete new version of the server from that definition, next to the one currently serving traffic — which keeps running, untouched.
Switch in one step. When the build succeeds and passes its checks, strackt switches the server to the new version.
Or roll straight back. If anything fails — the build, a health check, a service that won't restart — strackt switches back to the version that was running seconds ago. Your application never serves a broken state.
Keep the record. The previous version is kept, and the whole sequence — what changed, what triggered it, how it turned out — is recorded in your dashboard.
There's always a known-good state to return to
strackt keeps the previous working versions of your server, not just the current one — every successful change adds a version and keeps the ones before it. If a change causes trouble, even one that built and switched cleanly but misbehaves once it's live, strackt can switch the server back to an earlier version in seconds. It's the same single-step switch, run in reverse: no rebuild, no restore from a backup, no afternoon lost. The server returns to a state that provably ran before — the exact same server, not a reconstruction of it.
Rebuilding from nothing
The same property that makes rollback fast makes full recovery possible. Because your server is a definition rather than an accumulation of changes, strackt can take that definition and build the identical server again — on new hardware if the original is lost or replaced, or as a fresh copy. You get the same server back, not a hand-reconstructed approximation, in minutes rather than a day spent re-running setup from memory and half-remembered notes.
Experiment all you want — you can't break it for good
Because your server is defined rather than assembled, you're free to treat it like it's yours — because it is. Log in, install something, take a setting apart to see how it works, break things on purpose. The next time strackt runs an operation on your server, it brings the setup back to how it's defined. The fundamental configuration that keeps your system running is put back the way it should be.
So go ahead and experiment. The changes that matter can't quietly stick around and leave you with a server that no longer runs — strackt restores them on its next pass. It's almost impossible to kill a strackt server for good. Your application and its data are yours and stay untouched — strackt only ever resets the setup it manages, never your app or what's in it.
What the next operation brings back
- System packages and their versions.
- Services, users, and firewall rules.
- The settings that keep your server running.
What strackt never touches
- Your application code and its releases.
- Your database and everything in it.
- Uploads and files your application has written.
None of this is something you operate. If you want to see the specific tools behind it — and exactly what strackt can and can't touch on a server you own — that's in how strackt connects to your server.