What Is Stenvakt? The Beginner's Guide to Hardening Linux Servers Without Locking Yourself Out

CodexFuse Team · 2026-11-06T04:54:30.283Z · 25 min read min read

What Is Stenvakt? The Beginner's Guide to Hardening Linux Servers Without Locking Yourself Out

If you have ever wondered what is Stenvakt, the short answer is that it is a Mac app that reviews the Linux servers you run yourself over SSH, scores how secure and healthy each one is, and fixes firewall and SSH problems in safe mode. The server arms its own rollback timer before any risky change, so a bad change undoes itself instead of locking you out. Stenvakt appeared on Hacker News' Show HN on November 5, 2026, one day before this article was written, and this guide explains what it is, how its safe mode works, what it costs, and how it compares with Cockpit, Webmin, and Lynis.

Before you install any new server tool, keep one safety habit: if you download an installer or a script from a third-party mirror, check the file first with a SHA-256 hash generator before you run it. And if you run your own servers at all, a VPS hosting plan gives you a machine you control, which is exactly the kind of server Stenvakt is built to look after.

What is Stenvakt?

Stenvakt is a Mac app that patches the Linux servers you run yourself. It connects to each server over plain SSH with the keys you already use, and nothing new is installed on the server except what a fix names, such as ufw or fail2ban. Nothing new listens on the server, so there is no extra login page on the internet to protect.

The name is a small joke the maker explains on the site: Sten is stone, vakt is guard. Stenvakt is built by one person, in Croatia, who runs it on his own servers. That matters for what the tool is: it is narrow and opinionated, built for one job, rather than a platform that tries to do everything.

It runs on your Mac, on macOS 14 or newer, on Apple silicon machines. The servers it looks after are Linux machines, built and tested on Ubuntu and Debian, which are the systems most VPS hosts hand you.

AlmaLinux, Rocky, and other RHEL-family servers are recognised, but not every fix covers them yet. You need SSH access as root or as a user with passwordless sudo.

Stenvakt server hardening is the whole point of the app. It reviews a server, gives it a security score and a health score out of 100, and splits what it finds into three buckets: fix now, worth doing, and nice to have.

A review only reads. Nothing changes until you pick a fix, look at a preview of exactly what it will do, and run it.

How does Stenvakt work?

Stenvakt works in four steps: review, score, preview, and fix. First it reads the server over SSH and checks the firewall, SSH settings, updates, users, databases, backups, disk, and logs.

Then it scores security and health separately, so you can see at a glance whether a server is risky, unhealthy, or both. Then you preview any fix before it runs. Then the fix runs, with firewall and SSH steps protected by safe mode.

Fixes run in a fixed order: checks first, then updates, then firewall and SSH changes, and a reboot last. That order is deliberate. A reboot is the most disruptive step, so it goes at the end, after everything else has landed and been checked.

The findings it surfaces are concrete, not vague. On the demo servers shown on the homepage, the findings include Docker publishing sensitive ports to the internet, MySQL on port 3306 open to the internet, PostgreSQL on port 5432 open to the internet, password logins still allowed over SSH, root able to log in with a password, no firewall active, and no sign of backups on a server that runs a database. Each finding comes with an explanation of why it matters and what the fix does.

Two more parts sit beside the review. Watch reads each server's own logs over SSH, counting SSH guesses, firewall blocks, web bots, logins, and where they came from, and nothing is installed for it. Tools updates runtimes and services one at a time, compares services, listening ports, and containers before and after, stops at the first problem, and can undo the last update because the exact old versions are recorded.

Stenvakt also connects to AI coding agents such as Claude Code, Codex, and Cursor over MCP. Reading runs at once, and anything that changes a server waits for your approval in the app, unless it is a test server you marked as allowing agent changes.

Agents can never turn safe mode off, and they never see passwords, keys, or tokens. On October 25, Docker on the maker's own server had published ports 3001 and 8080 past the firewall, Claude Code proposed the block, the maker approved it in the app, safe mode ran, the new login worked, and the app cancelled the timer.

How does safe mode stop you from locking yourself out?

Safe mode is the feature the whole app is built around. Every firewall and SSH change runs through the same five steps, and the rollback timer lives on the server, not on your Mac. That last detail is what makes it work: even if your Mac sleeps, goes offline, or closes, the server still undoes the change on its own when the timer runs out.

1. Before a firewall or SSH step, Stenvakt saves the server's config and starts a rollback timer on the server itself: 300 seconds by default, or any window you set from 60 to 3600 seconds.
2. The app opens a brand-new SSH connection, the way you would log in tomorrow, instead of trusting the session already open.
3. If the new login works, the app cancels the timer and the change stays. There is no keep button to remember.
4. If the new login fails, the timer keeps counting on the server, whatever your Mac is doing: asleep, offline, or closed.
5. At zero, the saved config comes back and the server answers again, as it was before the change.

The homepage replays both endings on a demo server, web-1, blocking ports 3001 and 8080. In the success branch, the rollback is armed at 17:55:34, the new-login check runs at 17:55:36, and access is verified and the rollback cancelled at 17:55:39, five seconds later. In the failure branch, the new connection fails at 17:55:51, the app reports that the server will roll itself back in about 300 seconds, and the server answers again at 18:00:36.

That 302-second gap is the 300-second default timer plus about two seconds of overhead, which matches the stated default exactly. Safe mode covers firewall and SSH steps only, because those are the changes that can lock you out. Updates run without a timer, but Tools updates one thing at a time and can undo the last update.

The same idea exists as a manual habit, and it is worth knowing even if you never install Stenvakt. Before enabling a firewall change by hand, schedule the undo first, test a fresh connection, and only then cancel the undo. Never close your last working SSH session until a new one connects.

What does Stenvakt check on your server?

Stenvakt checks the security and health basics deeply, and it says so plainly. It does not run hundreds of tests the way an audit tool does, and it does not try to manage everything on the server. The review covers the firewall and network, SSH settings, updates and lifecycle, users and access, databases, backups and recovery, disk and logs, and CPU and memory.

Each server gets two scores out of 100, one for security and one for health, and every score is 100 minus the points lost in each category. The homepage shows four demo servers, and the arithmetic checks out on all eight scores: web-1 scores 66 for security because it lost 34 points, and 83 for health because it lost 17.

Shared-1 scores 58 and 79. Db-1 scores 71 and 62. Lab scores 49 and 91, the lowest security score of the four and the highest health score, which shows why the two scores stay separate: a fast, healthy server can still be wide open.

Firewall problems dominate the security losses. Three of the four demo servers lost 25 points to firewall findings alone: exposed databases, Docker publishing ports around the firewall, and no firewall active at all.

SSH findings cost shared-1 another 17 points and lab another 18, while users and access cost lab 8 more. On the health side, missing backups cost web-1 12 points and db-1 15, which is the single largest health loss on any demo server.

Watch turns the same review into ongoing monitoring. It reads the server's own logs and counts what is hitting it, and the demo figures show how noisy an internet-facing server is: 1,840 SSH guesses in the last day, up 136 percent on the day before, from 63 addresses.

The firewall blocked 960 of those attempts from 118 addresses, and fail2ban has 14 addresses banned right now. The web server fielded 6,120 requests, of which 2,310 returned 4xx errors and 40 returned 5xx errors. One country example breaks down to 1,612 events from the Netherlands: 412 SSH guesses, 300 firewall blocks, and 900 web requests, and 412 plus 300 plus 900 is exactly 1,612.

A review like this is only the first half of the job. If the scan finds something already wrong on a site, run a website malware scanner over it as well, and read how to remove malware from your website before you touch anything.

Hardening stops the next break-in; cleaning up the current one is a different job. The same goes for the web layer: a security headers checker scores the HTTP headers your site sends, which is a separate check from the server review Stenvakt runs.

Stenvakt Free vs Pro: what do you get?

Stenvakt is free in the parts that matter most, and the split is stated plainly on the pricing page. Review, Preview, and every fix you apply yourself run in safe mode, and safe mode, rollback, Preview, and Review will never move to Pro.

There is no server limit on any plan, free or paid. Pro is 4.99 euros a month or 39.99 euros a year, with a 14-day free trial.

The yearly price is worth checking, because the vendor's claim holds up exactly. Twelve months at 4.99 euros is 59.88 euros, and 59.88 minus 39.99 is 19.89 euros saved. Divide 19.89 by 4.99 and you get 3.99, so the yearly plan costs about four months less than paying monthly, just as the pricing page says.

Pro also adds expiry warnings and an exploit monitor, a weekly digest, agent proposals you approve in the app, and the careful tool updater. The trial runs for 14 days when you first open the app, with no account, and monthly and yearly plans also start with 14 days free, once per account.

Cancel during the trial and you are not charged, and when Pro ends the app goes back to Free and nothing is undone. Email within 14 days of any payment for a full refund.

An account is needed only to buy Pro, and the app never sees your password. Updates are free for everyone, and paying buys Pro features, not updates, so nobody's version is ever frozen.

One more plan exists on the pricing page, and it is not for sale yet. Autopilot is listed as soon, the next plan up, and it adds Polish: the whole server cleanup run for you, step by step, with proof.

Polish is built and tested on a lab server and is not released, and Autopilot is not on sale yet. The Team plan is custom priced, for several people, and you contact the vendor for it. Prices are in euros, and the price you see is the price you pay.

Stenvakt vs Cockpit: which one fits your servers?

Cockpit is a free, open-source web console that runs on each Linux server, sponsored by Red Hat and released under the GNU LGPL. You reach it in a browser on port 9090 by default, and it shows services, logs, storage, networking, the firewall, updates, and containers, with a terminal in the browser.

Fedora Server ships with it installed. Cockpit is for operating one machine, and it does that job well.

Stenvakt vs Cockpit is a choice between operating a machine and finding risk across several. Stenvakt reviews every server over SSH, ranks what is risky, and runs firewall and SSH fixes with a rollback timer on the server. It adds four things Cockpit does not try to do: an opinion that ranks findings as fix now, worth doing, or nice to have; safe changes with a rollback timer and a fresh-login proof; many servers at once, with a fleet score and the weakest server first; and history, meaning login attempts, firewall blocks, and score changes over time.

The vendor's own comparison puts it simply: Cockpit is for operating one machine, Stenvakt is for finding and fixing risks across several, and plenty of people use both. If you keep Cockpit, keep port 9090 closed to the internet or behind a VPN, because Stenvakt's review will flag it if it is open. That is the honest shape of the two tools: one shows you a firewall zone, the other tells you that PostgreSQL is reachable from the internet, that Docker publishes a port around ufw, or that SSH still accepts passwords, and ranks each as fix now, worth doing, or nice to have.

One timing note matters for this comparison. The vendor's guides were published on October 30 and November 1, 2026, days before the November 5 launch, and the Cockpit guide still says Stenvakt isn't out yet. That was true when the guide was written, and it is out of date now: the app launched on November 5, and the guides are a pre-launch ramp, not a current statement of availability.

Stenvakt vs Webmin: admin panel or hardener?

Webmin is a full admin panel installed on the server, running its own web server on port 10000 by default over HTTPS, running as root. It is free and open source, with about one million yearly installations worldwide according to its own site. Its modules cover users, Apache and nginx, BIND DNS, cron, file shares, packages, and much more, and its sibling Virtualmin turns the same base into a hosting panel.

Stenvakt vs Webmin is a choice between managing everything and locking down one thing. Pick Webmin when you want one place to manage everything from any browser. Pick Stenvakt when the job is keeping several servers patched and locked down, and you never want a change to cut off your own SSH access.

The lockout contrast is the sharpest difference. Webmin applies what you ask for, and if it was wrong, you need the hosting provider's console to get back in.

Stenvakt's safe mode rolls the change back on the server by itself. The vendor's Webmin guide also notes two past incidents in Webmin's history: a 2019 case in which some published downloads carried a backdoor, listed as CVE-2019-15107, and a 2022 access-control flaw, listed as CVE-2022-0824.

Both were fixed, Webmin is actively maintained, and IP allow-listing and two-factor authentication are its defences. The guide's point is not that Webmin is unsafe today, but that a panel listening on the open internet is itself a thing to protect.

You can use both. Stenvakt's review will simply tell you a panel is listening, and on which port. That is the pattern the vendor recommends for Cockpit too: keep the panel for operating the machine, and let the hardener watch the risk.

Stenvakt vs Lynis and hardening by hand

There are three ways to harden a Linux server you run yourself: work through a checklist by hand, audit it with a read-only tool such as Lynis and fix what it reports, or use an app that reviews and fixes for you. Each way has a real cost, and the honest choice depends on how many servers you run and how much time you have.

By hand is free, and it teaches you the most. It also costs time on every server, misses drift between checks, and carries the classic lockout risk: one wrong firewall rule, and you are in the provider console.

Lynis is the middle way. It is a free, open-source security auditing tool from CISOfy, released under the GPL and available since 2007.

It runs on the server itself, performs hundreds of individual tests, and prints warnings, suggestions, and a hardening index. Each test has an ID, such as SSH-7408, and the details go to a log file while the findings go to a report file. Lynis audits and reports, and the change is left to you.

Stenvakt is the third option: a Mac app that reviews your servers, explains each finding, and fixes the risky ones in safe mode with an automatic rollback. The trade is scope.

Stenvakt is not a general admin panel for mail, DNS, or file shares, and it does not run hundreds of tests the way Lynis does. It covers the security and health basics deeply, and it is opinionated about what matters most.

Choose by hand if you have one server and enjoy learning it. Choose Lynis for a second opinion on an already-hardened server. Choose an app with rollback if you have several servers, little time, and never want the hosting console again.

How do you harden a Linux server without locking out SSH?

Harden a Linux server without locking out SSH by auditing who logs in and how, before you change anything. The goal is to harden Linux server without locking out SSH.

On your own server, a bad change locks out one person: you. On a shared server, it locks out everyone who logs in a way you did not know about.

Start with the login history: last -i shows who logged in and from which addresses, and the journal shows each accepted login with the user, the method, and the source address. Check every authorized_keys file, and read the effective SSH config before you restart the service.

Do not turn off passwords until every password user has a working key. Use per-user Match blocks for stragglers, so one legacy account or deploy script keeps password access while everyone else moves to keys.

Test the result with the config test command before restarting SSH, and change one thing at a time so you know which change broke access if something goes wrong. Announce the change to the team first, and keep a non-SSH way back, such as the provider console.

Removing someone needs two steps, not one. Delete their key lines from every authorized_keys file, and lock the account too, because locking the password alone still lets key logins through.

When you do change the firewall, schedule the undo before you apply the change. The pattern the vendor's guide teaches is a timer that disables the firewall again after five minutes, which you cancel once a fresh connection works.

curl -fsSL https://stenvakt.com/install.sh | sh
sudo systemd-run --on-active=5m --unit=ufw-undo /usr/sbin/ufw disable
sudo ufw enable
sudo systemctl stop ufw-undo.timer

If you are already locked out after enabling ufw, SSH cannot get you back in, because the firewall drops it. Log in through your provider's web console instead, run sudo ufw disable or add the missing SSH rule, and SSH works again.

The server itself is fine, and rebooting will not help, because ufw starts at boot with the same rules. If there is no console, boot the provider's rescue system, mount the server's disk, and set ENABLED=no in the ufw config file on that disk.

The usual causes are all avoidable. Ufw was enabled before any rule allowed SSH, so the default deny drops it.

SSH moved to a new port, but ufw still allows only the old one. The SSH rule allows only one source address, and you now connect from another.

Or a limit rule blocked you after six or more connections within 30 seconds, which fixes itself in about a minute. Allow the new port in ufw before you restart SSH, and the lockout never happens.

What changes on a shared server?

Stenvakt was built for shared servers, and shared servers change one rule: the app never changes SSH access on a server you mark as shared, so nobody else loses their login. Its other fixes still run, and firewall steps still run in safe mode. The protection works because the app checks who logs in and how before it touches SSH, rather than assuming your login is the only one that matters.

The shared-server guide the vendor published walks through the same audit by hand. A shared server has a developer who still uses a password, a contractor with a key in someone else's authorized_keys, and a deploy script that logs in every night.

Each of those is a login the person making the change may not know about. The audit reads the login history, the journal, every authorized_keys file, and the effective config, and on Debian 13, where the last command no longer ships, the wtmpdb package provides the same history.

That is also why the golden rule matters more on shared servers than on your own. Announce the change, change one thing at a time, and keep a way back that does not depend on SSH. Stenvakt automates the second half of that rule with its rollback timer, but the first half, telling the team, is still yours.

Who is Stenvakt for, and who should skip it?

Stenvakt is for people who run their own Linux servers and want them hardened without babysitting the firewall. That is VPS owners, self-hosters, and small teams with a handful of servers each.

If you run one server and enjoy learning it, hardening by hand teaches you more. If you run dozens of servers with a fleet tool and a change process, a single Mac app is not your control plane. Stenvakt sits in the middle: several servers, little time, and a strong wish never to see the hosting console again.

The platform limits decide it quickly. The app is Mac-only, on macOS 14 or newer, on Apple silicon.

If your daily machine runs Windows or Linux, there is no client for you. The servers must be Ubuntu or Debian for full coverage, with AlmaLinux and Rocky recognised but not every fix covered yet. And you need SSH access as root or as a user with passwordless sudo, which rules out shared hosting accounts where you never get shell access at all.

One more honest note about the name. The phrase what is Stenvakt does not resolve on search yet: a quoted search for it this week returned unrelated results, including a Sindh education authority, stencil vectors, and a Python access-control package, and no page about the product.

The bare name is the keyword that resolves, through the vendor's own guides. That is normal for a product one day old, and it is why this guide targets the name itself rather than the question phrasing.

Stenvakt server hardening: the bottom line

Stenvakt is a narrow tool that does one job well: it reviews your Linux servers over SSH, tells you which ones are weakest, and fixes firewall and SSH problems in safe mode, with a server-side rollback timer that undoes a bad change by itself. The free tier covers the review, the preview, and the safe mode that makes the whole thing safe, with no limit on servers.

The paid tier adds monitoring, one-click fixes, backups, and a full audit report. The parts that are not ready yet are labelled as such: the Autopilot plan is not on sale, and the RHEL-family fixes are not all covered.

The comparisons are honest too. Cockpit operates one machine, Webmin administers everything, Lynis audits without fixing, and Stenvakt finds and fixes risk across several servers.

None of them is the wrong tool; they answer different questions. If your question is which server is weakest and how do I fix it without losing SSH, Stenvakt is the one built for that question.

Start with a review before you change anything, read the findings, and fix the firewall problems first: they cost the demo servers the most points, and they are the findings most likely to be exploited. Then turn off password logins, close the database ports, and set up backups.

CodexFuse does not offer a Stenvakt tool, and this guide is about the third-party product, not a CodexFuse service. If you want to check your own setup further, start with the free review, and keep the provider console password somewhere safe, because even the best rollback timer is no substitute for a way back in.

Sources

• Stenvakt, stenvakt.com, fetched November 6, 2026.
• Stenvakt pricing, stenvakt.com/pricing, fetched November 6, 2026.
• Cockpit vs Stenvakt, stenvakt.com/guides/cockpit-vs-stenvakt, published November 1, 2026.
• Webmin vs Stenvakt, stenvakt.com/guides/webmin-alternative, published November 1, 2026.
• Harden a Linux server: by hand, with Lynis, or an app, stenvakt.com/guides/harden-by-hand-or-with-a-tool, published November 1, 2026.
• Locked out after ufw enable, stenvakt.com/guides/ufw-locked-out, published October 30, 2026, updated November 1, 2026.
• Change SSH on a shared server without locking out your team, stenvakt.com/guides/shared-server-safe-changes, published October 30, 2026, updated November 1, 2026.
• Cockpit Project, cockpit-project.org, fetched November 6, 2026.
• Webmin, webmin.com, fetched November 6, 2026.
• Lynis, cisofy.com/lynis, fetched November 6, 2026.
• Fail2Ban, fail2ban.org, fetched November 6, 2026.
• Show HN: Stenvakt, a server hardening and patching tool, news.ycombinator.com/item?id=50386034, posted November 5, 2026.

Frequently Asked Questions

Is Stenvakt free?

Yes. The review, the preview, and safe mode with its rollback timer cost nothing, and there is no cap on how many servers you review. The paid tier adds monitoring, one-click fixes, scheduled backups, and a full audit report, with a 14-day free trial.

Does Stenvakt work on Windows or Linux desktops?

No. Stenvakt is a Mac app only, for macOS 14 or newer on Apple silicon. The servers it manages are Linux machines, with Ubuntu and Debian fully covered and AlmaLinux and Rocky partly covered so far.

Can Stenvakt lock me out of my own server?

That is the failure the app is built to prevent. Every firewall and SSH change arms a rollback timer on the server, 300 seconds by default and adjustable from 60 to 3600 seconds, and the change is kept only after a fresh SSH login succeeds. If the login fails, the server restores its saved config when the timer runs out.

Is Stenvakt a replacement for Webmin or Cockpit?

No. Stenvakt does not manage mail, DNS, or file shares, and it is not a general admin panel.

Webmin administers everything from a browser, Cockpit operates one machine from a browser, and Stenvakt hardens several servers over SSH. Many people use a panel and Stenvakt together.

What is the difference between Stenvakt and Lynis?

Lynis is a free, open-source auditing tool that runs hundreds of tests on a server and reports warnings, suggestions, and a hardening index, but it changes nothing. Stenvakt reviews a server the same way, then fixes the risky findings itself, with every firewall and SSH fix protected by a rollback timer.