What is on sale

Three blade servers, each a proper dual-CPU machine with a generous amount of ECC RAM, the kind of box you actually want for virtualization, containers or a busy database:

Every one of them ships with 192 GB of ECC RAM minimum (288 GB on the BL490c), 24 cores across two Xeons, up to 2x SAS/SATA drives with RAID 0 or 1, dual 1 or 10 Gbit/s networking, 25 TB of monthly traffic and 10 IPv4 + 10 IPv6 addresses. All hosted in Bucharest on our own AS57050 network, with free peering at DSIX.

Why all that RAM matters

192 GB is a lot of memory for the money, and memory is exactly what you run out of first when you virtualize. On one of these blades you can comfortably run a dozen or more VMs or LXC containers, a Proxmox lab, a Kubernetes node pool, or a memory-hungry database, without the constant “out of RAM” juggling you get on smaller boxes. Dedicated cores, dedicated RAM, no noisy neighbours.

They are also a bargain per gigabyte: at 100 EUR for 192 GB of ECC RAM plus 24 cores, the summer price works out to well under a euro per gigabyte of real, dedicated memory.

The only catch: it ends September 1

There is no catch on the hardware, only on the clock. The discount is live now and disappears on September 1. Order before then and the price is locked for the whole term of your service: it does not jump back up at renewal.

See the blade servers →

Enjoy the last days of summer, and let one of these blades do the heavy lifting while you are at the beach.

This is a short, practical post: what RoPay is, why we like it, and exactly how you pay with it, step by step.

What RoPay is

RoPay is Romania’s instant account-to-account payment scheme. Instead of typing a card number, you initiate a payment by scanning a QR code (or tapping a link on your phone), and you approve it inside your own bank’s mobile app with your usual authentication, fingerprint, face or PIN. The transfer settles in real time, in seconds, directly from your bank account to ours. No card network in the middle, no card details shared with anyone.

We integrated RoPay through Libra Internet Bank , our partner bank on the scheme. For you as a customer, the bank on our side does not matter: what matters is that your bank is one of the Romanian banks enrolled in RoPay, which by now is almost all of them.

Why we added it

Three honest reasons:

• It is instant. The invoice is marked paid the moment you confirm in your app, so your service is provisioned or renewed without the “waiting for the payment to clear” limbo.
• It is safer. You approve the exact amount and merchant inside your trusted banking app. You never type card details into a payment page, so there is nothing to skim or leak.
• It is cheaper, and we pass that on. Card processing carries hefty fees. RoPay does not. Paying by RoPay costs a flat 0.5%, noticeably less than a card, which is money that stays in your pocket.

How to pay with RoPay, step by step

1. Open your invoice in the DreamServer client area and choose RoPay as the payment method, then click pay.
2. A payment page appears showing the amount in RON and a RoPay QR code.
3. Open your bank’s mobile app on your phone, find its “scan QR to pay” or RoPay feature, and scan the code. If you are already on your phone, just tap the “Open in app” button and it will jump straight into your banking app.
4. Check and confirm. Your app shows the amount and that the payment goes to DreamServer. Approve it the way you always do, fingerprint, face or PIN.
5. Done. The payment lands in seconds, the page confirms it automatically, and your invoice is marked paid. No screenshots to send us, no “please confirm my payment” ticket.

That is the whole flow. The first time takes a curious extra ten seconds while you find the QR feature in your app; after that it is faster than reaching for your wallet.

Good to know

A few honest details so there are no surprises:

• RoPay works in RON only. It is a Romanian domestic instant-payment scheme, so it settles in lei. If your invoice happens to be issued in EUR or USD, the RoPay page will tell you and offer to open a ticket. Just ask and we will reissue the invoice in RON so you can pay it with RoPay.
• You need RoPay active in your banking app. You need a Romanian bank account at a RoPay-enrolled bank, with the feature switched on. Most Romanian banking apps have it under names like “instant payments”, “RoPay” or “pay by QR”.
• Not sure how your bank does it? Open your banking app and look for a “scan to pay”, “QR” or “RoPay” option, usually near transfers or payments. If you cannot find it, your bank may ask you to enroll or activate RoPay once, a one-minute, one-time step that links your account to the scheme. After that, every future payment is just scan and confirm.
• The QR is single-use. Each payment generates a fresh QR, so if you leave the page and come back, you will get a new code. That is by design, for security.

Try it on your next invoice

RoPay sits right next to our existing payment methods, so nothing you already use goes away, you simply have a faster, cheaper option now. Next time an invoice is due, pick RoPay, scan, confirm, and get on with your day.

If you are new here and want something to pay for, our VPS plans are a good place to start, and if you would rather we run the server for you, our server administration service has you covered. Either way, when the invoice arrives, RoPay will be waiting, one scan away.

This is where a bastion earns its keep. And Warpgate , the open-source bastion written in Rust by the warp-tech team, solves exactly that pain without asking you to reinvent your whole access story. We have been testing it in front of a handful of servers in our Bucharest datacenter for a few weeks. This post is the field report.

What Warpgate actually is

In short: Warpgate is a transparent proxy that sits between you and your internal infrastructure and needs absolutely no client-side software. You install no agent, you run no wrapper around ssh, you force no new tool on the team. You keep running ssh, opening VSCode Remote, pasting a MySQL connection string into your favourite client, logging into a web panel from the browser. Warpgate slots itself onto the path, authenticates, applies the access policy, and only then hands the connection off to the real target, all while recording a live session for audit.

The “transparent” part is the crux and worth underlining. Warpgate is not a classic jump host, where you log into an intermediate box and then fire a second ssh at the destination. The difference is subtle but important: from a jump host you take two hops, you need keys on the middle box, you juggle ProxyJump and agent forwarding. Warpgate finishes authentication in front of you and then hands off to the server in a way that is fully transparent to the client. From your point of view, you run a single command and you are on the server. From a security point of view, every byte that flows was inspected, attributed to an identity, and saved.

Why being written in Rust actually matters

It may sound like a fan detail, but it has practical consequences. Warpgate is 100% safe Rust, with its own SSH implementation (the russh library), a web plane on the poem framework, and state persisted to SQLite through sea-orm and sqlx. The admin interface is a modern Svelte 5 frontend.

What this means operationally: a single binary, no external dependencies, no heavy runtime to patch, and none of the memory-safety vulnerability class (buffer overflows, use-after-free) that haunted network software written in C for three decades. For a service that by definition sits exposed at the edge of your network and is the first to see every access attempt, “safe by construction” is not a marketing slogan, it is exactly the property you want.

Which protocols it covers

Warpgate started life as an SSH bastion, but it has grown a lot. As of today it exposes native listeners for:

• SSH, the classic case: shell access to servers, with full session recording.
• HTTPS, to put any internal web application (an admin panel, a Grafana, a router) behind the same authentication gate.
• MySQL and PostgreSQL, so database connections also flow through the bastion, with the same identity and audit model.
• Kubernetes, for kubectl access to clusters through the same control point.
• RDP and VNC, added more recently, for remote desktop sessions.

All through the same binary, the same admin UI, the same user and role model. You are not juggling six different tools; you have a single place where you say who reaches what.

What you get out of the box

The open-source edition, which is the only edition, is generous. Warpgate is licensed under Apache-2.0, has more than 7,400 stars on GitHub, and is actively developed. Out of the box you get:

• Native two-factor authentication (2FA) via TOTP. That is the code generator from Google Authenticator, Aegis or any other app, with no SMS gateway to pay for.
• Single Sign-On through OpenID Connect, to tie Warpgate to your identity provider (Authelia, Keycloak, Google Workspace, Azure AD). A user logs in once, with the company identity, and gets exactly the access you assigned them.
• Full session recording, with live viewing and later replay directly from the admin UI. You can watch in real time what is being typed in an SSH session, or come back two weeks later and replay exactly what happened.
• Command-level audit, not just “the user connected at 14:32” but what they ran there.
• Precise access control, with fine-grained assignment between users, roles and targets. A user sees and touches only the services assigned to them, nothing else.
• Brute-force protection, with IP blocking and user lockout, so nobody turns your port 2222 into a playground.
• A single binary, no dependencies, that boots in seconds and moves easily from one place to another.

What it does not do, and it is worth being clear: Warpgate is not a VPN and it is not a secrets vault. It does not encrypt your whole network segment end to end for all traffic; it gives you a controlled access gate to specific services. It does not replace a HashiCorp Vault for secret rotation. It is one piece of an access strategy, not the whole strategy.

Installing Warpgate on a VPS

This is the part where many “self-hosted PAM” projects make you regret the decision, burying you under a three-hundred-line helm chart and five external dependencies. Warpgate genuinely does not. Being a single Rust binary, the install is almost embarrassingly simple.

Sane starting resources: 1 vCPU and 1 GB RAM comfortably run a bastion for a small team; step up to 2 vCPU / 2 GB if you record many concurrent sessions or push database traffic. SQLite keeps state locally, so you need no separate database server.

On a fresh Debian or Ubuntu server, grab the binary from the official releases:

ver=v0.26.1
wget https://github.com/warp-tech/warpgate/releases/download/$ver/warpgate-$ver-x86_64-linux
chmod +x warpgate-$ver-x86_64-linux
sudo mv warpgate-$ver-x86_64-linux /usr/local/bin/warpgate

Then run the interactive setup, which generates your config file, the host keys and the first admin account:

sudo warpgate --config /etc/warpgate.yaml setup

Setup asks which ports each protocol should listen on. The defaults are chosen well so they do not clash with services already on the box:

• SSH: port 2222 (not 22, so it does not collide with the host’s sshd).
• HTTPS admin UI: port 8888.
• MySQL: port 33306.

Data and session history land in a SQLite database under /var/lib/warpgate. After setup, start the service:

sudo warpgate --config /etc/warpgate.yaml run

For production you obviously wrap it in a systemd unit with Restart=always, so it comes back up after a reboot. If you prefer containers, there is an official Docker image plus a helm chart, but for a single-node bastion the binary straight on the host is the cleanest option: fewer network layers between an attacker and your logs.

One hygiene step you never skip: the admin UI on 8888 must not be exposed to the whole world. Restrict it to your management IPs with a firewall rule:

ufw allow 2222/tcp
ufw allow from YOUR_OFFICE_IP to any port 8888 proto tcp
ufw deny 8888/tcp

If you are running this on a DreamServer VPS , the same rule belongs in your provider’s network firewall too, do not rely on host-level rules alone for management interfaces.

Adding a target and a user

The mental model takes a minute to click, but after that it is clear. Warpgate has three entities that combine: targets (the servers and services you want to grant access to), users (the people who connect) and roles (groups that bind users to targets).

In the admin UI at https://<your-server-ip>:8888/, you first add an SSH target: its name inside Warpgate (say web-prod), the real address and port of the origin (10.0.0.5:22), and how Warpgate authenticates onward to the server, with a dedicated SSH key you generate for the bastion. That key goes into authorized_keys on the target, and it is the only one that needs to live there: from that moment, people no longer keep personal keys scattered across servers, they all go through the bastion.

Then you create a user, enable 2FA (or tie them through OIDC to the company identity provider), and assign them to a role that has access to web-prod. Done. The user connects like this:

ssh admin:web-prod@bastion.example.com -p 2222

The user:target@host syntax is the whole trick: the part before the : is the Warpgate identity, the part after is the name of the target you want to reach. Warpgate authenticates you (password plus TOTP code, or an OIDC redirect in the browser), checks that you are allowed on web-prod, and drops you on the server. For databases, same model, the syntax just differs slightly:

mysql -u 'admin#web-db' --host bastion.example.com --port 33306 --ssl -p

For HTTPS targets, you open the Warpgate UI in the browser, authenticate, and click the target: the bastion proxies the internal web application through its authenticated gate, without exposing the application directly to the internet.

Configuration patterns worth knowing

A few things we found genuinely useful beyond the defaults.

Enforce 2FA for everyone, from day one

A bastion without a second factor is just SSH with extra steps. Turn on mandatory TOTP for all users on the first day, before anyone gets used to living without it. The cost is a QR-code scan; the benefit is that a stolen password alone no longer opens anything.

Tie it to OIDC and skip manual account management

If you already run an identity provider, OIDC integration turns Warpgate from “yet another place I keep passwords” into “yet another service that respects the company identity”. When a person leaves, you disable their account in one place, the IdP, and their access to everything that flows through the bastion vanishes instantly. That alone solves the scenario we opened this article with.

Review the recordings, do not just let them sit

The real power of session recording is not that it exists, it is that you use it. Once a week, go into Sessions in the UI and walk through what happened on the sensitive targets. You will catch things: someone who ran a DROP on the wrong database, a contractor who touched a server that was not their job, an incident nobody reported. Replay is something you simply cannot get from a text log.

One target = one dedicated bastion key

Do not reuse the same SSH key for all targets. Generate one pair per server, held by Warpgate. If you ever need to pull a server out of the bastion or rotate a key, you do it surgically, without touching access to the rest of the fleet.

Treat the SQLite database as critical infrastructure

All the configuration and all the session history live in /var/lib/warpgate. The container or binary can be rebuilt in a minute; the SQLite database is what you would actually miss. Put it in a real backup story, a Proxmox Backup , snapshots, your call, and test that you know how to restore it.

Where Warpgate is not the right answer

It is worth being honest about the limits.

• Not a VPN. Warpgate gives you controlled access to specific services, not a general network tunnel. If you need a laptop to “be on the network” for dozens of ad-hoc services, a VPN (or WireGuard) remains the complementary tool, not the replaced one.
• Not a secrets vault. It does not auto-rotate database passwords or inject ephemeral credentials Vault-style. It stores the bastion’s own access keys, and that is it.
• SQLite has a ceiling. For a normal-sized team and fleet, SQLite is perfect. For tens of thousands of long-retained sessions or aggressive multi-node HA setups, plan carefully, export and archive old recordings instead of letting the database grow forever.
• Self-hosting is not free. You are running another stateful service that needs backups, OS patching and occasional attention. If your team does not want that, managed bastions exist, but you will pay in a different currency, money and control.

Alternatives we considered

For completeness: we also looked at Teleport (extremely capable, with short-lived certificates and infrastructure access at scale, but much heavier and with key features pushed toward the commercial edition), sshpiper (a pure SSH reverse proxy, minimalist, no UI and no session recording), Apache Guacamole (excellent for RDP/VNC in the browser, but centered on remote desktop rather than the multi-protocol bastion model) and a plain hardened SSH jump host (cheap, familiar, but no real audit and the same key-sprawl problem we set out to solve).

Warpgate ended up being the cleanest fit for “I want a real bastion, with 2FA and session recording, in front of a small-to-medium fleet of self-hosted servers, without adopting a whole platform”. Your weights might be different.

So, should you run it?

If you manage more than a handful of servers and you have reached the point where you can no longer say for certain “who has access to what and what did they do there”, Warpgate is worth a Sunday afternoon. The install is genuinely fast, the access model settles into your head quickly, and the first time you replay a recorded session to understand an incident, you will know it has earned a permanent place in your stack.

If you run it in production, treat it as a bastion deserves: minimally exposed, with the admin UI locked to trusted IPs, with 2FA enforced, and with the SQLite database backed up. The bastion is, by definition, the single road to the rest of your infrastructure, so it deserves care to match.

We run Warpgate ourselves in front of a couple of internal services and recommend it to customers who ask how to bring order to their SSH access. If you want to try it on infrastructure you do not have to build first, our VPS plans start at small enough sizes to make the experiment cheap, and our server administration service covers the install, OIDC integration and tuning if you would rather skip the learning curve.

Either way, kicking the tires on Warpgate is a better way to spend an evening than counting the keys in authorized_keys one more time, hoping you recognise all of them. The code is on GitHub, the install is practically a single command, and you will know within an hour whether it earns its place in front of your infrastructure.

Domain Monitor , created and maintained by Hosteroid, is an open-source, MIT-licensed tool built to solve exactly that: it tracks the expiry of your domains and notifies you early, on a channel you actually check. We evaluated it as an alternative to relying on registrars’ native notification systems, which vary wildly in reliability from provider to provider.

What Domain Monitor actually is

Domain Monitor is a PHP 8.1+ application, built on its own custom MVC framework (not Laravel or Symfony), with MySQL 5.7+ or MariaDB 10.3+ as the data backend and Composer-managed dependencies. The core idea: add your domains to the app, and a cron job periodically runs WHOIS/RDAP lookups for each one, automatically extracting the expiry date and current registrar. As a domain approaches expiry, the app fires notifications at whatever thresholds you configure (default: 60, 30, 21, 14, 7, 5, 3, 2, and 1 days out).

It supports over 1,400 TLDs, with direct integration against the IANA registry to determine the correct WHOIS/RDAP server for each extension, including a dedicated TLD registry importer.

Why this matters

The difference from relying on registrar emails is having a single place that aggregates all your domains, no matter how many different registrars they’re spread across (a common reality once you’ve bought domains over several years or inherited them from clients). And multi-channel notifications (not just email, which gets lost in the noise) mean a Slack, Discord, or Telegram ping can hit you directly when a threshold actually matters, not just at the 60-day mark you ignore because “there’s still time.”

What you get out of the box

• Unlimited domain management: add, edit, bulk import, and manual or automatic WHOIS refresh.
• Smart WHOIS/RDAP lookups, with automatic detection of expiry date and current registrar, across 1,400+ TLDs.
• Multi-channel notifications: Email, Telegram, Discord, Slack, Mattermost, Pushover, and custom webhooks.
• Notification groups: organize channels and flexibly assign domains to different groups (useful when different clients or teams own responsibility).
• Real-time dashboard showing the status of every domain and active alerts.
• Complete notification history, with detailed logging.
• Cron-based automated monitoring, with configurable check intervals.
• Database-backed session system, tracking geolocation, ISP, and device, with the ability to remotely terminate any active session instantly.
• Randomly generated passwords at install time, and cryptographically secure “Remember Me” tokens (30-day duration).
• Prepared SQL statements throughout, as a standard defense against injection.

Installing Domain Monitor on a VPS

The project ships dedicated Docker support in the domain-monitor-docker directory of the repo. A typical flow on a fresh VPS:

git clone https://github.com/Hosteroid/domain-monitor.git
cd domain-monitor/domain-monitor-docker

docker compose up -d

Once it’s up, the app exposes a browser-accessible web installer that automatically creates the database tables, generates the encryption key, populates the .env file, and shows you the generated admin credentials once (write them down immediately).

If you prefer a traditional install without Docker, you’ll need PHP 8.1+, MySQL/MariaDB, Composer, a webserver with URL rewriting support (Apache with mod_rewrite or Nginx), and cron access for automation.

On the VPS firewall, only allow what’s strictly needed publicly:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

The app itself is light on resources (plain PHP, no heavy frontend framework), so an entry-level VPS is more than enough, even for a few hundred monitored domains.

Configuration patterns worth knowing

Per-client notification groups, not one global channel

If you manage domains for multiple clients or projects, don’t dump every alert into a single Slack channel where it gets lost. Use notification groups to route each client’s domains to their own channel (a dedicated email, a webhook into their ticketing system, or their own Slack), keeping ownership clear.

Risk-adjusted notification thresholds

The default thresholds (60 down to 1 day) are a solid starting point, but tune them per domain category. A critical production domain deserves an extra 90-day threshold plus escalation at the 24-48h mark (a different channel, maybe a phone alert via Pushover), while a test domain can stay on the defaults.

Remote session termination for teams

If multiple people have access to the admin panel, use the active sessions feature with geolocation and remote termination to instantly cut off access from a lost or compromised device, instead of waiting for the session to expire naturally.

Manual WHOIS refresh after a renewal

After renewing a domain directly at the registrar, use the manual refresh in the UI instead of waiting for the next automatic cron cycle, so the dashboard reflects the new expiry date right away and doesn’t fire a false alert in the meantime.

Where Domain Monitor is not the right answer

If you only own one or two personal domains, spinning up a PHP app with a dedicated database is overkill, your phone’s calendar or a simple recurring reminder does the job just as well. Domain Monitor also doesn’t auto-renew domains, it’s strictly a monitoring and alerting tool, it doesn’t connect to the registrar to renew on your behalf (that stays your responsibility or the registrar’s). And if you’re already a client of a registrar or hosting provider that includes expiry monitoring in its control panel, check whether that existing coverage is enough before adding another app to administer.

Alternatives we considered

• WhoisFreaks or other commercial WHOIS APIs: a good fit if you need very high query volume and don’t want to run anything yourself, but they come with a recurring cost and third-party dependency.
• The registrar’s native reminders: free and already active if all your domains sit with one registrar, but reliability varies a lot, and you get no unified view if your domains are spread across registrars.
• DomainMOD : another self-hosted tool, more geared toward a full inventory of domains/hosting/SSL rather than pure expiry monitoring.

So, should you run it?

If you manage domains for clients, or simply have accumulated more than you can keep track of in your head, a dedicated expiry-monitoring tool is cheap to run and expensive to skip. As a registrar and LIR ourselves, we know firsthand how often an emergency ticket comes in for exactly this reason, and a unified dashboard with alerts on the right channel costs a lot less than recovering an expired domain.

Want to run it on your own VPS , or would you rather not deal with the operational side at all? Our server administration service covers exactly that. And if you’d rather offload .ro renewals entirely, check our .ro domain registration service.

Cronmaster is an open-source project, licensed under AGPL-3.0, that puts a modern web UI on top of the cron jobs running on a host (or a container), with human-readable syntax, live logging, and proper authentication. We evaluated it as an alternative to hand-editing crontab on servers where you actually want visibility into what’s running and when.

What Cronmaster actually is

Cronmaster is a Next.js + TypeScript app, styled with Tailwind CSS, shipped as a single Docker container. Instead of shelling out to crontab commands under the hood, it reads and writes the host’s crontab file directly, which lets it stay in sync with the actual system state in real time, even while Cronmaster itself runs containerized next to the host’s cron.

The UI shows your existing jobs in plain English (“every day at 3:00 AM” instead of 0 3 * * *), lets you create, edit, clone, and delete jobs straight from the browser, and ships with presets for common schedules so you’re not googling cron syntax for the tenth time.

Why this matters

The real problem with cron isn’t that it doesn’t work, it’s that it’s opaque. When a job fails silently at 4am, you find out only once someone notices the report is missing or the backup never ran. This is exactly what Cronmaster addresses: optional per-job logging (stdout, stderr, exit code, timestamp) with automatic cleanup, and live updates over Server-Sent Events, so you can watch a long-running job execute in real time from your browser instead of tail -f-ing some log file.

What you get out of the box

• Modern, responsive UI with dark/light mode.
• System monitoring: uptime, memory, CPU, GPU, and network info for the host, right in the same dashboard.
• Cron job management: create, edit, delete, clone, with human-readable syntax and quick presets.
• Bash script management: create and manage scripts straight from the UI, for use inside jobs.
• Optional execution logging, with automatic history cleanup, capturing stdout/stderr/exit code/timestamps.
• Live updates via SSE: real-time status and log streaming for long-running jobs.
• Smart execution: jobs with logging enabled run asynchronously with background updates; jobs without logging run synchronously with a 5-minute timeout.
• Full REST API, with optional API key authentication, for external integrations.
• Flexible authentication: simple password, OIDC/SSO (Authentik, Auth0, Keycloak, Okta, Google, Entra ID), or both at once.
• Localization across multiple languages, with support for custom translations.
• ARM64 and AMD64 support, so it runs on a Raspberry Pi just as well as an x86 VPS.

Installing Cronmaster on a VPS

Cronmaster runs exclusively as a container, and the official image is on GHCR. The minimal setup from the project’s README:

cat > docker-compose.yml << 'EOF'
services:
  cronmaster:
    image: ghcr.io/fccview/cronmaster:latest
    container_name: cronmaster
    user: "root"
    ports:
      - "40123:3000"
    environment:
      - NODE_ENV=production
      - AUTH_PASSWORD=your_strong_password
      - HOST_CRONTAB_USER=root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./scripts:/app/scripts
      - ./data:/app/data
      - ./snippets:/app/snippets
    pid: "host"
    privileged: true
    restart: always
    init: true
EOF

docker compose up -d

Notice it runs privileged: true, mounts the Docker socket, and shares pid: host, because it needs direct access to the host’s crontab and, optionally, to other containers. That’s a high level of trust handed to the container, treat it accordingly (isolate it on a dedicated VPS, not next to other apps holding sensitive data).

For the firewall, only expose the UI port (40123 here) behind a TLS-terminating reverse proxy, never directly public without authentication already configured:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

A modest VPS is enough for Cronmaster itself, but size it based on whatever runs inside the jobs you’re managing, not the management app.

Configuration patterns worth knowing

SSO instead of a shared password

If more than one person on the team needs access to the same cron jobs (say, DevOps plus on-call), configure OIDC instead of a shared password. Cronmaster supports any standard OIDC provider, so it plugs into whatever you already have (a self-hosted Keycloak, or Google/Entra ID if you’re already on those). You can enable both methods at once, handy for a local break-glass account plus SSO for everyone else.

Selective logging, not blanket logging

Don’t flip logging on for every job by default. Jobs without logging run synchronously with a strict 5-minute timeout, which is fine for short, deterministic tasks. Jobs with logging run asynchronously, making them the right choice for anything that runs longer or produces output you want to inspect later. Mixing the two up can produce unexpected timeouts on jobs that actually needed background execution.

API key for external integrations

If you already have an alerting system or an internal dashboard, use the REST API with API key authentication instead of scraping the UI. Full documentation lives in howto/API.md in the repo, and the API lets you read job status and logs programmatically, exactly what you need to fold Cronmaster into a broader monitoring flow.

Reusable script snippets

The bash script management feature lets you keep reusable code snippets attached to jobs. Instead of copy-pasting the same shell block into ten different jobs, you keep it in one place and reference it, cutting the risk that a fix gets applied to nine out of ten copies.

Where Cronmaster is not the right answer

If you have a single machine with two or three simple, stable cron jobs, spinning up a privileged container for that is overkill, just edit crontab directly and move on. Cronmaster also doesn’t replace a real workflow orchestrator (Airflow, Temporal, or even a job scheduler with proper retry logic and task dependencies); it’s still cron underneath, with the same limitations (no sophisticated automatic retries, no dependency DAGs). And given the privileged: true requirement plus Docker socket access, don’t put it on a multi-tenant host or a machine with other sensitive apps without seriously thinking through isolation first.

Alternatives we considered

• Cronicle : a more complete scheduler with clustering and job dependencies, but a steeper learning curve and a heavier install than a single container.
• Plain crontab + healthchecks.io (self-hosted as Healthchecks ): keep cron simple and just bolt on monitoring via HTTP heartbeats, without changing how you manage jobs.
• Ofelia : a minimalist Docker scheduler defined via container labels, no UI, but very lightweight if you’re already orchestrating everything with Docker Compose.

So, should you run it?

If you manage more than a handful of cron jobs and have ever caught yourself manually checking whether last night’s backup ran, Cronmaster is worth trying. The human-readable UI and live logging save real time, and the SSO support is welcome the moment you’re not the only one who needs access. Just weigh the privilege requirements seriously before putting it on anything that matters.

Want a dedicated VPS for your ops tooling, isolated from the rest of your infrastructure? Or would you rather hand off the setup and maintenance entirely? Our server administration service covers exactly that.

ArchiveBox (site: archivebox.io ) is an open-source, MIT-licensed tool built for exactly that problem: you give it a URL, and it saves a complete copy, in multiple formats at once, on your own server. We run ArchiveBox in our Bucharest datacenter to stop link rot on our own reference material and internal documentation before it becomes a problem.

What ArchiveBox actually is

ArchiveBox is built on Django and Django-Ninja, with SQLite for persistent metadata storage. When you feed it a URL, it doesn’t take a single snapshot, it orchestrates a set of proven tools to produce, simultaneously: a full HTML snapshot (original HTML+CSS+JS), a “SingleFile” page (the whole page bundled into one self-contained HTML file), a PDF, a PNG screenshot, a WARC file (the same standard format used by the Internet Archive), extracted article text, the favicon, HTTP headers, and downloaded media via yt-dlp when the page contains video or audio.

Every URL becomes a “snapshot” with its own folder, an HTML index, and all the formats above sitting next to each other. You’re not betting on a single format staying usable (a PDF that renders wrong later, an HTML page that lost its external CSS), you always have redundant copies.

Why this matters

The difference from a plain wget or a manual screenshot is redundancy plus automation. If you’re archiving sources for an article, evidence for a legal matter, or just your own research history, you want to be able to open the archive in five years regardless of what’s changed in browsers or file formats by then. WARC is the same format used by the Internet Archive’s Wayback Machine, so you get compatibility with established replay tooling. You’re effectively building your own Wayback Machine, one you actually control.

What you get out of the box

• Multiple ways to add URLs: CLI (archivebox add <url>), a REST API (beta), a browser bookmarklet, or bulk import from browser history, bookmarks, Pocket, Pinboard, Reddit, or RSS feeds.
• Full-text search across everything you’ve archived, powered by Sonic (a fast, lightweight search engine).
• Web UI (Django Admin plus its own interface) for browsing, searching, and managing snapshots.
• Scheduled importing: configure RSS/JSON/CSV sources that get checked periodically, and any new URL gets archived automatically.
• An official browser extension (ArchiveBox Exporter, also available in the Chrome Web Store) for one-click archiving straight from the current tab.
• Optional redundant backup to archive.org, if you want a copy outside your own infrastructure too.
• The client interface uses plain HTML/CSS/JS with no heavy frontend framework, so it runs comfortably even on a modest VPS.

Installing ArchiveBox on a VPS

The officially recommended method is Docker Compose. A minimal docker-compose.yml setup looks like this:

mkdir archivebox && cd archivebox
curl -O https://raw.githubusercontent.com/ArchiveBox/ArchiveBox/dev/docker-compose.yml

docker compose run archivebox init --setup
docker compose up -d

This creates a data/ folder with your archive and starts the web server on port 8000 by default. Create an admin account with:

docker compose run archivebox manage createsuperuser

If you’d rather skip Docker, the package is also available via uv, apt, brew, or pacman, depending on your distro.

Once it’s running, only expose it publicly behind a TLS-terminating reverse proxy (Nginx, Caddy, or Traefik), never the raw port. On the VPS firewall itself, allow only 22 (SSH), 80, and 443:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Budget reasonable resources: headless Chrome/Chromium for rendering, plus generous disk space if you’re archiving media (yt-dlp can pull down large files). A VPS with at least 2 vCPUs and enough SSD for your archive’s growth is a solid starting point.

Configuration patterns worth knowing

Auto-importing from recurring sources

Instead of adding every URL by hand, configure archivebox schedule or an external cron job that runs archivebox add --index-only against an RSS feed or a periodically refreshed bookmark export. That turns ArchiveBox from a reactive tool (you archive when you remember) into a proactive one (it archives everything you post or read automatically).

Picking extractors selectively

You don’t need all 10+ formats for every archive. If you’re running on a small VPS and only want text plus PDF (skipping video, skipping heavy WARC files), disable specific extractors in ArchiveBox.conf (settings like SAVE_WARC=False or SAVE_MEDIA=False). This dramatically cuts disk usage and per-URL processing time.

Keeping big archives off the root disk

If your archive grows (media, full WARCs), you don’t want to fill up the VM’s root filesystem. Mount a separate disk at data/archive/ before you start archiving large volumes, exactly like you would for any app whose data keeps growing.

Full-text search via Sonic

Sonic runs as a separate container next to ArchiveBox and indexes the extracted text content. If your archive grows into thousands of pages, full-text search is what makes the tool actually useful, otherwise you’re browsing by title and date alone.

Where ArchiveBox is not the right answer

If all you need is “save me 20 links once a month,” ArchiveBox is overkill, a plain bookmark manager or even the public Wayback Machine (web.archive.org/save) gets it done without you having to run a server. It’s also not a CMS or a publishing tool, archives are meant for your own reference, not for serving as a high-traffic public site (even though technically you could). If your goal is real-time content monitoring (detecting changes on a page, alerting), look for a dedicated change-detection tool instead of an archiver. And if you legally need notarized, timestamp-certified archives (admissible evidence with a strict chain of custody), talk to a provider specialized in legal archiving, raw WARC files don’t give you that out of the box.

Alternatives we considered

• SingleFile : a browser extension that saves a page as a single HTML file. Great for one-off captures, but no orchestration, search, or central archive management.
• Wayback Machine (archive.org) : the Internet Archive’s public service. Free and simple, but you don’t control retention, and some pages block their crawler (robots.txt, geo-blocking).
• Monolith : a minimalist Rust CLI that bundles a page into a single HTML file. Fast and lightweight, but no UI, search, or multi-format output.

So, should you run it?

If you produce or rely on content that matters long-term, cited articles, research material, evidence, external documentation you link to, ArchiveBox is a cheap tool (resource-wise) that solves a real and often-ignored problem. We run it for exactly that in our Bucharest datacenter, and we haven’t been caught out by a dead link to something we actually needed to reread since.

Need a VPS to put it to work, or would you rather not handle the day-to-day operations yourself? Our server administration service covers exactly that, from install through updates and monitoring.

That’s exactly what WatchYourLAN (github.com/aceberg/WatchYourLAN) is built for. It’s an open source project written in Go: it ARP-scans your subnet, remembers every host it finds, with MAC address, hostname, interface, and online/offline history, and puts all of it in a simple web UI, plus a /metrics endpoint for Prometheus. We run it ourselves, across our own network in our Bucharest datacenter: we run one instance per internal segment where we want direct visibility, and the results feed into our Grafana stack through that /metrics endpoint. We’re not selling it as a product, it’s an internal operational tool we’ve found useful enough to write about.

What WatchYourLAN actually is

WatchYourLAN doesn’t do anything exotic, and that’s precisely its strength. It runs periodic ARP scans across one or more configured interfaces/subnets, and for every MAC address it finds, it records: the current IP, hostname (if it can be resolved), the interface it was seen on, online/offline status, and first-seen/last-seen timestamps. All of that gets written to a local SQLite database, so there’s no separate database server or heavy external dependency to run. Everything you see in the web UI, a list of hosts with IP, MAC, name, interface, and a known/unknown flag, comes straight out of that history.

On top of the UI, it exposes a /metrics endpoint in Prometheus format, which means you can scrape that data into whatever monitoring stack you already have, without writing the integration yourself from scratch. It’s written in Go, runs comfortably in a container, and is designed to work with host networking, because otherwise it has no way to actually see the real ARP traffic on the physical interface or VLAN you want to monitor.

Why it matters

A network inventory “on paper” (or in a spreadsheet last updated six months ago) lies to you constantly. Real network state changes daily: someone plugs in an unmanaged switch to add a few more ports, a test box stays powered on after the project ends, an IoT device shows up out of nowhere on the wrong VLAN. None of these show up in a quarterly audit, but all of them show up immediately in an ARP scan. WatchYourLAN answers “what’s actually alive on this segment right now, and since when,” which is exactly the kind of signal you want when you’re trying to spot unwanted equipment or simply confirm your network segmentation looks the way you think it does.

What you get out of the box

• A web UI listing every discovered host: IP address, MAC address, hostname/name, network interface it was seen on, and a known/unknown flag.
• Online/offline history per host, with first-seen and last-seen timestamps, so you can answer “since when has this thing been connected” without digging through logs.
• A Prometheus-compatible /metrics endpoint, ready to scrape for dashboards and alerts in Grafana or anything else that speaks the Prometheus format.
• Local storage in SQLite, no heavy external dependencies, easy to back up or reset.
• A lightweight Go binary that runs well in a container, typically with host networking so it can actually see real network traffic.

Installing WatchYourLAN on a VPS

The simplest way to try WatchYourLAN is in a container, with access to the interface you want to scan. A minimal docker run example:

docker run -d \
  --name watchyourlan \
  --network host \
  --restart unless-stopped \
  -e TZ=Europe/Bucharest \
  -e IFACES=eth0 \
  -v /docker/watchyourlan/data:/data \
  aceberg/watchyourlan:latest

Or, if you prefer docker compose:

services:
  watchyourlan:
    image: aceberg/watchyourlan:latest
    container_name: watchyourlan
    network_mode: host
    restart: unless-stopped
    environment:
      - TZ=Europe/Bucharest
      - IFACES=eth0
    volumes:
      - ./data:/data

The data volume holds the SQLite database, so keep it persistently mounted if you don’t want to lose host history on a container restart. The web UI runs on its own port, and if you expose that port outside the box, mind your ufw rules: don’t leave it open publicly without restriction. Either bind it to an internal address or a VPN only, or put it behind a reverse proxy with authentication, because a list of hosts, MAC addresses, and interfaces is effectively a map of your network topology, not something you want exposed to whoever happens to pass by.

One thing worth saying plainly: on a typical VPS, with a single network interface in a public cloud, WatchYourLAN has a narrower use case. ARP scanning only works within the same broadcast domain, and a standard VPS usually sits isolated from other tenants on the provider’s network, so it has nothing to “see” belonging to neighboring machines. Where it genuinely shines is on a segmented network, with VLANs or subnets you control, whether that’s internal infrastructure or a private network/VPC environment where host networking actually gives you access to real traffic. If you have a VPS with us and want to try the tool for a narrower use case (say, monitoring a private network reachable over a VPN into that VPS), you can start from our VPS page; for more complex topologies with multiple VLANs, our network page has more context.

Configuration patterns worth knowing

Scan interval

WatchYourLAN scans periodically, not continuously, and the interval between scans is a trade-off between “I see changes near real time” and “I’m not generating unnecessary ARP traffic on the network.” For a small or critical VLAN, where you want to catch a newly connected device quickly, a short interval makes sense. For a large segment with hundreds of hosts, a more relaxed interval avoids turning the scan itself into constant background noise. There’s no universally correct value, it depends on how often your network actually changes and how fast you want to know.

Known versus unknown

The known/unknown host flag is, in our opinion, the most practical feature of the whole UI. Once you’ve marked the hosts you expect (servers, workstations, network gear), any new appearance jumps out immediately as “unknown,” instead of getting lost in a long list of IPs. It’s worth making a habit of periodically going through the list and marking what’s legitimate, otherwise the “unknown” list itself becomes noise you learn to ignore.

Wiring /metrics into Prometheus and Grafana

Because WatchYourLAN exposes /metrics in Prometheus format, integrating it into an existing stack is straightforward: add a scrape job pointing at that endpoint, and from there you can build Grafana panels for online host counts per VLAN, new hosts that appeared in the last 24 hours, or alerts when a known, important host suddenly disappears from the network. That’s exactly what we do: our scan results land in Grafana alongside the rest of our infrastructure metrics, so we get one view, not a separate tab we forget is open.

One instance per VLAN/segment

If your network is segmented (and it probably should be), the cleanest model is running one WatchYourLAN instance per VLAN or subnet that matters, each with visibility limited to that interface/segment. That gives you both isolation (one broken or compromised instance doesn’t take down your visibility elsewhere) and clarity in the dashboard: you know exactly which VLAN is reporting what. That’s the approach we use internally too, one instance per segment that needs direct visibility.

Where WatchYourLAN is not the right answer

Let’s be honest: WatchYourLAN is not an IPAM. It doesn’t manage your IP allocations, doesn’t track reserved subnets or address planning, it just tells you what’s alive right now. For an authoritative source of truth on topology, allocations, and infrastructure documentation, a dedicated CMDB/IPAM tool (we use NetBox internally for that) is still necessary.

It’s also not a complete NAC (Network Access Control) or 802.1x solution. It tells you what it sees, but it doesn’t decide who’s allowed to connect and doesn’t block anything at the switch port level. If you need identity-based network access control, you need something alongside it, not instead of it.

It’s not a vulnerability scanner either. It tells you a host exists at an address, not what services are running on it or whether it has exploitable ports open. For that you need a dedicated, separate scanner.

And perhaps the most important technical detail: ARP scanning only works within the same broadcast domain. It can’t “see” past a router, so on a routed network with multiple separate subnets, you need an instance (or visibility) on each segment individually, not one magic instance covering everything.

Alternatives we considered

Before settling on WatchYourLAN for our use case, we looked at a few other options, some complementary, some direct competitors:

• nmap with custom scripts and a database behind it (often Postgres), for teams who want full control over scan format and what gets stored. Flexible, but you build all the persistence and UI yourself.
• arp-scan, the command-line tool that many other discovery tools conceptually build on. Great for one-off scans or custom scripting, but no persistent history or UI out of the box.
• Netdisco, an older project more focused on switch-level/topology discovery (including SNMP), useful when you want more than a plain ARP scan and also need switch port mapping.
• Fing, best known in its small/home network variant, focused on ease of use and mobile apps.
• Network discovery modules in Zabbix or PRTG, if you already run one of these monitoring systems in production and want discovery as an add-on feature rather than a separate tool to administer.

Each of these has its place. We picked WatchYourLAN for how easy it is to deploy per segment, and because /metrics plugs directly into our existing Grafana stack without adding another separate piece of software to manage.

So, should you run it?

If you run a segmented network and want to be able to answer “what’s connected here right now, and since when” at any moment, WatchYourLAN is a lightweight, free tool that’s honest about what it does: an ARP scanner with memory and a metrics endpoint, nothing more, nothing less. You can try it on one of our VPS instances if you want to play with it in an isolated environment, and if you want it properly wired into a segmented network with VLANs, with a discovery and monitoring workflow set up from scratch, our server administration team can handle the configuration and integration, so you’re not left with yet another tab you only check once a month.

OpenMediaVault (openmediavault.org ) sits in between: a complete NAS distribution built on Debian but managed entirely from a web interface, licensed under GPLv3. We evaluated it as an option for anyone who wants the convenience of a commercial box but on their own hardware, with full control over the system underneath.

What OpenMediaVault actually is

OpenMediaVault (often shortened to OMV) is, at its core, a stable Debian install with a management layer on top: a daemon and a web interface (built on Angular/PHP) that translates clicks in a friendly UI into system commands - creating software RAID, sharing over SMB, configuring users and permissions, monitoring disks. It’s the spiritual successor to the old FreeNAS (before it became TrueNAS), but built on Debian/Linux instead of FreeBSD, which means broader hardware and driver compatibility.

Redundant storage relies on two complementary mechanisms: software RAID via mdadm (classic RAID1/5/6/10 at the Linux kernel level) for real-time redundancy, and SnapRAID, a more unconventional tool that computes parity information periodically (not in real time), suited for archives of data that don’t change often - photos, movies, backups - where you don’t need instant protection against a dead disk, but you do want to be able to rebuild the data if it happens.

What makes OMV genuinely useful long-term is its plugin system, omv-extras: an additional package repository that extends the base install with ZFS support, Docker/Portainer integration for running containers directly on the storage box, cloud backup clients and more, all without leaving the web UI.

Why this matters

The difference from a commercial NAS box isn’t only hardware cost. With a closed firmware, you’re at the vendor’s mercy for how long you keep getting security updates and what features get added or dropped in a new release. With OMV, you have a standard Debian underneath: you can install any package from the Debian repositories, upgrade the operating system independently of OMV, and if the OMV project itself disappeared tomorrow, you’d still have a working Linux server with Samba and mdadm configured, not a sealed box turning into e-waste.

What you get out of the box

• A full web interface for managing disks, volumes and shares, no command line needed for day-to-day operations
• File services: SMB/CIFS (Windows/macOS/Linux), NFS (Linux/Unix), FTP, SSH, rsync
• Software RAID via mdadm (RAID0/1/5/6/10) plus SnapRAID as an alternative for rarely-modified data
• User and group system with per-share permissions, plus support for external authentication (LDAP/AD)
• SMART monitoring for disks, email notifications on events and thresholds
• A plugin system (omv-extras) for ZFS, Docker/Portainer, cloud clients and more
• Support for x86_64 and ARM architectures (including Raspberry Pi), useful for low-power boxes

Installing OpenMediaVault on a VPS

Let’s be upfront: OpenMediaVault is designed for physical hardware with dedicated disks, not a regular VPS with a single virtual disk. That said, it can make sense to test your configuration or run a management/monitoring instance on a VPS before deploying to physical hardware, or to validate a new plugin without touching the production box.

# install on a clean Debian machine (classic path, on top of an existing OS)
wget -O - https://packages.openmediavault.org/public/archive.key | gpg --dearmor | tee /etc/apt/trusted.gpg.d/openmediavault-archive-keyring.gpg
echo "deb [signed-by=/etc/apt/trusted.gpg.d/openmediavault-archive-keyring.gpg] https://packages.openmediavault.org/public sandworm main" \
  | tee /etc/apt/sources.list.d/openmediavault.list
apt update
apt install openmediavault-keyring
apt update
apt install openmediavault

After install, the web UI listens on port 80/443 by default, and the initial login uses the admin user. In a VPS test environment with no extra physical disks attached, you can still practice configuring SMB/NFS shares on the main volume, though you won’t be able to demonstrate RAID or SnapRAID without separate attached disks.

# web admin interface
ufw allow 80/tcp
ufw allow 443/tcp
# SMB/CIFS
ufw allow 445/tcp
ufw allow 139/tcp
# NFS (portmapper + nfsd; exact port differs between NFSv3 and NFSv4)
ufw allow 2049/tcp
ufw allow 111/tcp
# FTP, if you enable it
ufw allow 21/tcp

On a VPS, consider restricting these rules to a single IP or a private network rather than exposing SMB/NFS publicly - these are protocols designed for trusted local networks, not the open internet.

Configuration patterns worth knowing

Choose RAID or SnapRAID based on the data type

For data that changes frequently and needs immediate availability after a disk failure, mdadm (RAID1/5/6) is the right call. For relatively static archives - media libraries, periodic backups - SnapRAID gives you the flexibility to add disks of different sizes at any point, something classic RAID doesn’t allow easily.

Don’t skip SMART monitoring

OMV has native integration with smartmontools, but email notifications need to be configured explicitly (SMTP server, temperature threshold, reallocated-sector threshold). A disk that starts throwing SMART errors weeks before it fully dies is exactly the scenario where you want to be alerted automatically, not to find out after you’ve already lost data.

Plugins mean an extra repository, not magic

omv-extras adds a package repository on top of standard Debian. Before enabling experimental plugins (especially community ones, not official ones), check which OMV version they’re actively maintained against - the project evolves, and abandoned plugins can end up incompatible after a major upgrade.

Docker through OMV vs. Docker managed manually

The Docker/Portainer plugin is convenient for running a handful of extra containers (say, a cloud sync service) directly on the NAS box, but if your plan is to run a complex, actively maintained Docker stack, consider separating it onto a dedicated machine - a NAS loaded with too many roles becomes harder to troubleshoot when something breaks.

Where OpenMediaVault is not the right answer

If you need storage for a production environment with serious availability requirements (automatic failover, multi-node replication), OMV isn’t built for that - it’s a single-node NAS solution. For that, look at Ceph or a dedicated cluster storage solution instead.

Also, on a regular VPS with a single virtual disk already redundant at the hypervisor level, most of OMV’s value (software RAID, SnapRAID, SMART monitoring on physical disks) simply doesn’t apply. OMV earns its place on physical hardware, with multiple disks mounted directly.

Finally, if all you need is a simple SMB share and nothing more, a standalone samba install without the OMV management layer stays easier to reason about and troubleshoot for anyone already comfortable with plain Linux.

Alternatives we considered

• TrueNAS CORE/SCALE : built on native ZFS (CORE on FreeBSD, SCALE on Debian/Linux), with more advanced enterprise storage features, but higher hardware requirements (especially RAM for ZFS)
• Unraid : a commercial (not free) solution very popular in the home-lab space, with a flexible parity model similar to SnapRAID, but a paid license
• Samba + mdadm managed manually: for anyone who wants full control with no management layer on top, at the cost of configuring everything from the command line

So, should you run it?

OpenMediaVault makes clear sense when you have dedicated physical hardware - a mini-PC, a repurposed old server, an ARM board with a few USB or SATA disks attached - and you want a friendly interface over Debian without giving up the flexibility of a standard Linux underneath. It’s not, however, the right tool for storage on a regular VPS, where the virtual disk is already managed by the hypervisor.

If your plan is to pair a local OMV NAS with offsite backups or with services running in the cloud alongside it, a VPS is the right place for the networking and externally-reachable services side of things, and if you’d rather have someone handle maintenance and monitoring for the whole setup, check out our server administration service and our network section for context on how all of this fits together in a full infrastructure.

That’s the exact problem Pterodactyl was built to solve. It’s a free, open source game server management panel, MIT licensed , with the code on GitHub and documentation at pterodactyl.io . We run it ourselves: DreamServer’s dedicated game server hosting is built on Pterodactyl, precisely so customers get a real self-service panel instead of a support ticket queue for routine tasks like restarting a server or swapping a mod pack.

What Pterodactyl actually is

Pterodactyl splits into two pieces, and understanding that split is the key to understanding everything else about it.

The Panel is the web application, built on PHP and Laravel. It’s what you and your users see: the dashboard, user accounts, the server list, billing hooks if you wire it up to something like WHMCS. The Panel doesn’t run any game servers itself, it’s the control plane: it knows what servers exist, who owns them, what resources they’re allotted, and it talks to the machines that do the actual work.

Those machines run Wings, a daemon written in Go that lives on each game server node. Wings starts, stops, and manages the game server processes, launching each one inside its own Docker container. That’s the detail that matters most operationally: every game server is isolated. A crashed or misbehaving Rust server can’t take down the Minecraft server next to it on the same box, because they don’t share a process space, and resource limits (CPU, RAM, disk) are enforced per container rather than being a polite suggestion.

The third piece is eggs: a templating system describing how to install, configure, and run a specific type of game server. An egg for Paper Minecraft knows how to download the right jar, generate the startup command, and expose the right config variables in the Panel UI. Official and community eggs exist for hundreds of games: Minecraft in all its flavors (Vanilla, Paper, Forge, Fabric), Rust, ARK: Survival Evolved, Valheim, Terraria, CS2 and other Source-engine titles, and plenty more. Adding support for a new game doesn’t mean patching Pterodactyl itself, it means writing or importing an egg.

Why it matters

The obvious win is self-service. A restart, a mod swap, a look at the console to see why the server crashed: none of that needs an admin with SSH access anymore. That’s exactly the model behind our dedicated game server hosting : the servers are Pterodactyl-managed, so a customer running a Minecraft or Rust server gets full self-service control without needing shell access to the host.

The less obvious win is safety. Docker isolation means a container that eats all its allocated RAM gets killed by Docker, not by taking the whole host down with it. Per-server resource limits mean one noisy neighbor can’t starve everyone else’s server on the same node, whether you’re running this for six friends or six hundred paying customers.

What you get out of the box

• Eggs for hundreds of games, covering the obvious ones (Minecraft variants, Rust, ARK, Valheim, Terraria, CS2) and plenty of community-maintained niche titles.
• Per-server resource limits: CPU, RAM, and disk quotas enforced through Docker, so allocations are actual guarantees, not gentleman’s agreements.
• SFTP access per server, so users can manage worlds, configs, and mods directly without needing shell access to the host.
• A live console in the browser, streaming stdin/stdout, so you can watch a server boot or debug a crash without a terminal.
• Subusers, letting you hand a friend or a community moderator limited permissions on one specific server, without giving them the keys to your whole panel.
• Scheduled tasks and backups, so restarts, world backups, or command execution can run on a timer instead of needing a human to remember.
• A REST API, for anyone who wants to script server management, tie it into a Discord bot, or integrate it with a billing system.
• Multi-node scaling: one Panel can manage many Wings nodes, which can be spread across different physical machines or even different locations.

Installing Pterodactyl on a VPS

A realistic install has two moving parts that can live on the same box (fine for a small setup) or on separate machines (what you want once you’re running more than a handful of servers).

The Panel wants a fairly standard web stack: PHP, MariaDB or MySQL, Redis, and a web server in front (Nginx or Caddy). The official install path is a web-based installer after you pull the code and get Composer dependencies in place. Community-maintained Docker Compose setups also exist if you’d rather run the whole Panel stack as containers.

A typical bare-metal-style Panel setup looks roughly like this:

# System dependencies (Debian/Ubuntu example)
apt update && apt install -y php8.3 php8.3-{cli,gd,mysql,mbstring,bcmath,xml,curl,zip,intl} \
  mariadb-server nginx redis-server curl tar unzip git composer

# Pull the panel and install PHP dependencies
mkdir -p /var/www/pterodactyl && cd /var/www/pterodactyl
curl -Lo panel.tar.gz https://github.com/pterodactyl/panel/releases/latest/download/panel.tar.gz
tar -xzvf panel.tar.gz && chmod -R 755 storage/* bootstrap/cache/
composer install --no-dev --optimize-autoloader

# Environment + database migration (interactive)
cp .env.example .env
php artisan key:generate --force
php artisan p:environment:setup
php artisan p:environment:database
php artisan migrate --seed --force
php artisan p:user:make

Wings, the daemon that actually runs game servers, is a separate install and itself relies on Docker to launch containers. The modern, standard path is to run Wings as a systemd-managed service (or as a container) on each node you want to host servers on:

# On each Wings node (needs Docker installed first)
mkdir -p /etc/pterodactyl
curl -L -o /usr/local/bin/wings \
  "https://github.com/pterodactyl/wings/releases/latest/download/wings_linux_amd64"
chmod u+x /usr/local/bin/wings

# Grab a node token from the Panel's admin UI, then:
wings configure --panel-url https://panel.example.com \
  --token <node-token> --node <node-id>

systemctl enable --now wings

For a small setup, Panel and Wings on the same VPS or dedicated server is perfectly fine. Once you’re running enough concurrent players or servers that CPU contention becomes a real concern, splitting Wings onto its own dedicated box (or several, one per region) is the natural next step, and the Panel handles multiple nodes without any architectural change.

Ports to open depend on what’s running where. The Panel needs the standard web ports, Wings exposes its own API port, and each game server needs whatever port range you allocate for it:

ufw allow 80/tcp        # Panel HTTP (redirect to HTTPS)
ufw allow 443/tcp       # Panel HTTPS
ufw allow 8080/tcp      # Wings default API/SFTP port (adjust to your config)
ufw allow 25565:25665/tcp   # example game server port range (Minecraft-style)
ufw allow 25565:25665/udp   # if your games need UDP too

This is exactly the kind of workload that fits well on a DreamServer VPS or a dedicated box: predictable CPU and I/O, Docker support out of the box, and enough headroom to run Panel, Wings, and a handful of game servers side by side without stepping on each other.

Configuration patterns worth knowing

Split Panel and Wings across nodes early

If you expect this to grow past a hobby project, don’t wait until you’re CPU-starved to separate Panel and Wings. Put the Panel on a small, low-resource box (it’s mostly PHP and a database), and size Wings nodes for the actual game workloads. Different regions can run their own Wings nodes pointed at the same Panel, which is how you’d offer, say, an EU and a US location from one admin interface.

Pick eggs deliberately

Egg quality varies. Official eggs tend to be solid and kept up to date; community eggs range from excellent to abandoned. Before committing a game to production, read the egg’s install script and startup command. For something unusual (a specific mod loader version, custom plugins baked into the image), you may end up forking or writing your own egg rather than trusting a random one you found.

Set resource limits with headroom

A container that hits its memory limit gets killed by Docker’s OOM handling, which for a game server usually means an ungraceful crash, not a clean shutdown. Size RAM limits with a margin above what the process normally needs (Minecraft with a big modpack is the classic case where people set -Xmx right at the container limit and wonder why it dies under load). CPU limits are softer: Docker throttles rather than kills, so a tight CPU limit just means lag.

Use subusers, and put backups off-node

Give trusted community admins subuser access to their specific server rather than sharing the owner’s login: permissions are granular enough for console access and file management without handing over billing or delete rights. And decide deliberately where backups live: local backups protect against a corrupted world file, not a dead disk. Pterodactyl supports S3-compatible storage as a backup destination, the sane default for anything a community actually depends on.

Lock the Panel down like the admin interface it is

The Panel has full control over every server it manages, so treat access accordingly: two-factor authentication for admin accounts, a small number of full-admin users, and HTTPS with a real certificate, not a self-signed one users have to click through.

Where Pterodactyl is not the right answer

If you’re running exactly one Minecraft server for yourself, with nobody else needing access and no need for a web UI, Pterodactyl is overkill. A game binary in a systemd unit or a tmux/screen session, with a couple of shell aliases for start/stop/backup, has essentially zero overhead and nothing to maintain beyond the game itself. Panel plus Wings plus MariaDB plus Redis is real infrastructure that needs updates, monitoring, and patching. That’s a fair trade when you’re managing servers for other people, and a bad trade when you just want your own Valheim world up on weekends.

It’s also not a universal fit for every game server binary out there. Anything that doesn’t containerize cleanly, or expects direct hardware access, can be awkward to wrap in an egg. And egg quality is uneven: popular games are well covered, obscure ones may have a thin or unmaintained egg, or none at all, meaning you’re writing your own.

Alternatives we considered

Crafty Controller : simpler and more narrowly focused on Minecraft. If Minecraft is genuinely the only game you’ll ever run, Crafty’s lower complexity is a real advantage over Pterodactyl’s broader, heavier stack.

AMP (Application Management Panel) : commercial-friendly, broad game support, and a polished out-of-box experience from CubeCoders. Not fully open source the way Pterodactyl is, and licensing costs scale with usage, but a legitimate option if you want a supported commercial product.

Pelican Panel : a newer, Pterodactyl-inspired fork with its own development direction. Worth watching, though less battle-tested simply by virtue of being younger.

Plain systemd or tmux/screen: for the single-server, single-admin case, this is genuinely the right answer. No web stack, no Docker layer, just the game process and your shell.

So, should you run it?

If you’re managing more than one or two game servers, or if anyone besides you needs to touch them, Pterodactyl earns its keep. The Panel plus Wings architecture, Docker isolation, and the egg system cover a genuinely wide range of games with real safety guarantees around resource limits, and the self-service model means you stop being the bottleneck for routine requests.

If you’d rather skip building that stack yourself, our dedicated game server hosting runs on Pterodactyl already: you get the Panel, console, SFTP, and subuser access without standing up the infrastructure. If you want to run your own install, a DreamServer VPS is a solid place to put Panel and Wings, and our server administration service can keep it patched while you focus on the game servers themselves.

Databasement , the open-source database backup manager written by David Courty , solves exactly that swamp with a single web interface. It is licensed under MIT, has more than 1,800 stars on GitHub, and we run it self-hosted in our Bucharest datacenter. This post is the field report.

What Databasement actually is

Databasement is a centralized backup manager for databases. Instead of cron scripts scattered across every server, you have a single web application where you define the database servers, say what to back up and how often, where the backups should go and how long to keep them, and the application handles the rest: it runs the dumps on schedule, compresses them, uploads them to the chosen storage, and gives you a restore button when you need it.

Its tagline, “your backups deserve a safe place to live”, is not just marketing. The core idea is that a backup is a flow, not a file: it is taken, moved off-site, kept according to a policy, and must be restorable. Databasement models exactly this flow, with visibility on every step.

Which databases and destinations it covers

This is where Databasement is surprisingly complete for an open-source project. Out of the box it supports:

• Databases: MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, MongoDB, SQLite, Firebird and Redis/Valkey. Basically anything you might run.
• Storage destinations: local, S3-compatible (AWS, MinIO, Backblaze), Azure Blob, Samba/SMB, SFTP and FTP. A backup that stays on the same server is not a backup, and Databasement makes off-site destinations easy.
• Compression and encryption: gzip, zstd, or AES-256 for encrypted backups.
• SSH tunnels and remote agents: to reach databases behind a bastion or in a private network, without exposing the database port.
• Notifications: email, Slack, Discord, Telegram, Pushover, Gotify and webhooks, so you find out immediately when a backup fails.

On top of all that, it has access control with SSO (Google, GitHub, GitLab, OpenID Connect), 2FA and role-based permissions, plus a REST API and even an MCP server for automation. It is far more than “a cron with a UI”.

Installing Databasement

Databasement is a Laravel application packaged neatly into a single container. The simplest variant gets you running with SQLite as the internal configuration store, so you do not need a separate database just to run the backup manager:

docker run -d --name databasement -p 2226:2226 \
  -e DB_CONNECTION=sqlite \
  -e DB_DATABASE=/data/database.sqlite \
  -e ENABLE_QUEUE_WORKER=true \
  -e PUID=1000 -e PGID=1000 \
  -v ./databasement-data:/data \
  davidcrty/databasement:1

You bring the container up, open the UI on port 2226, create your admin account on first access, and from there add the database servers and backup jobs from the interface.

One detail that matters a lot and deserves underlining: ENABLE_QUEUE_WORKER=true is not optional if you want scheduled backups. Databasement runs its scheduler in the same process as the queue worker. Without this flag, the app starts, the UI works, but scheduled jobs never fire, because there is nobody to execute them. It is the classic trap you fall into if you follow a minimalist compose. We run it exactly in this mode, single-container with the worker on, precisely so the scheduler is alive.

As with any tool that holds credentials to all your databases, do not expose it publicly without authentication. It has native login, but we also keep it behind our SSO, because an application that can perform destructive restores on production deserves a double fence. At minimum, restrict it with a firewall and put a reverse proxy with TLS in front.

If you are running this on a DreamServer VPS , remember that the backups themselves must land in off-site storage (S3, another server), not on the same disk, otherwise a single incident takes the database and the backup with it.

Configuration patterns worth knowing

A few things useful beyond the defaults.

The backup must leave the server

The golden rule: a backup on the same disk as the database does not save you from a disk failure or ransomware. Configure an off-site destination (S3, SFTP to another server, SMB) from day one. Databasement makes this part of the job definition, use it.

Test the restore, not just the backup

A backup you have never restored is a theory, not a safety net. Use Databasement’s cross-server restore to periodically restore a backup into a test database and confirm the data is there. The day you need a restore is not the day you want to discover the dump was corrupt.

Tiered retention

Do not keep everything forever, but do not keep only the last copy either. A healthy policy is a few dailies, a few weeklies, a few monthlies. Databasement supports per-job retention policies, exactly so you do not fill your storage while still having historical depth.

SSH tunnels for private databases

Never expose port 3306 or 5432 to the internet just so the backup tool can reach it. Databasement connects through an SSH tunnel or a remote agent, so the database stays in its private network and the backup still reaches it.

Where Databasement is not the right answer

It is worth being honest about the limits.

• Not file or whole-machine backup. Databasement takes database dumps. For files, volumes or VM images you need a different tool (a Proxmox Backup , restic, borg). The two complement each other.
• Not a replacement for replication. A daily backup gives you a recovery point from yesterday, not real-time failover. For availability you need replication or a cluster; the backup is the safety net, not HA.
• The restore is your responsibility to test. The tool gives you the button, but the confidence only comes from pressing it periodically on real data.
• It is another stateful service to maintain. It has its own SQLite database, its own credentials, its own UI to patch. Worth it, but you treat it as infrastructure, with a backup of its own configuration.

Alternatives we considered

For completeness: we also looked at classic mysqldump/pg_dump scripts plus cron (they work, they are free, but they quickly become a swamp with no visibility, notifications or easy restore), at Bacula and Bareos (very capable enterprise backup systems, but heavy and file-centric rather than database-centric), and at cloud-native solutions (RDS snapshots and the like, excellent if you are already there, useless self-hosted). For “I want a single place where I see and schedule the backups of all my databases, with one-click restore”, Databasement is the most on-target.

So, should you run it?

If you manage more than one database and your current backup is a cron script you have not checked in months, Databasement is worth the afternoon of setup. The first time you see in the dashboard all your databases with the last backup green next to each, with schedules and retention and off-site storage, and you know you can restore any of them with one click, you will understand the difference between “I hope I have a backup” and “I know I can recover”.

We run Databasement single-container, with the worker on so the scheduler is alive, behind our SSO, for our infrastructure’s databases. If you want to try it on infrastructure you do not have to build first, our VPS plans are perfect for a small backup manager, and our server administration service covers the install, the storage destinations and restore testing if you would rather skip the learning curve.

Either way, getting your database backups in order is the cheapest insurance in IT. The code is on GitHub, there is a public demo you can touch right now, and you will know within an hour whether it earns a spot in your infrastructure.

That’s the itch Nextcloud scratches. It’s open source (AGPLv3), the code lives on GitHub , and at its core it’s a file sync and share platform you install on your own server, backed by your own database, on storage you control. We say this because we actually run it: DreamServer offers managed Nextcloud hosting out of our own Bucharest datacenter, meaning the data doesn’t transit through a third party’s infrastructure at all, it sits on our storage, behind our network, inside Romania. For companies with GDPR obligations, or public sector and healthcare clients who need to point at a specific physical location and say “that’s where it is,” that distinction matters, not as a compliance checkbox but as a real answer to a real question.

What Nextcloud actually is

Calling Nextcloud “a Dropbox clone” undersells it. Files is the core app: desktop clients for Windows/macOS/Linux, mobile apps for iOS/Android, and a web UI, keeping folders in sync in real time with the usual conflict handling and offline queueing. But Files is just the entry point into an app ecosystem that turns the same install into a fairly complete internal collaboration platform:

• Talk for chat, voice, and video calls (including group calls), useful if you want your team communicating on infrastructure you control rather than a SaaS chat tool.
• Calendar and Contacts, both speaking standard CalDAV/CardDAV, so they sync with Thunderbird, Apple Calendar, or any other standards-compliant client.
• Mail, a webmail client living inside the same interface, plus Deck, a Trello-style kanban board for lightweight project tracking.
• Notes, plus dozens more apps in the built-in app store covering everything from forms to whiteboards.
• Online document editing through integration with Collabora Online or OnlyOffice, both separate open source projects that plug into Nextcloud so you can co-edit a Word or Excel file in the browser without ever touching Microsoft 365.

On storage, Nextcloud isn’t limited to its own disk: you can mount S3-compatible object storage, FTP, SMB/CIFS shares, or other WebDAV servers as external storage, so it can sit in front of storage you already have rather than forcing a migration.

Why it matters

Strip away the app list and the actual pitch is data sovereignty. When you run Nextcloud yourself, or have someone run it for you, instead of handing files to Google Workspace or Microsoft 365, you know exactly which server, which datacenter, which country your data sits in. For a Romanian or EU company with GDPR obligations, that’s not a nice-to-have, it’s the difference between a straightforward compliance answer and a lengthy explanation involving Standard Contractual Clauses and a lawyer. It’s why we built this into our own service lineup: our Nextcloud storage hosting runs on infrastructure we own end to end, so the answer to “where’s the data” is “in our Bucharest datacenter,” full stop.

What you get out of the box

Once it’s running, day-to-day Nextcloud gives you a fairly complete replacement for the file-sharing habits most teams have picked up from consumer cloud tools, minus the seat-based pricing anxiety:

• Sync clients for desktop and mobile that keep local folders mirrored against the server, with selective sync so you’re not forced to mirror everything to every device.
• Share links with configurable expiry dates, optional passwords, and permission levels (view-only, upload-only, edit), so sending a client a file doesn’t mean emailing an attachment into the void.
• File versioning, so an overwritten or accidentally-deleted file has a history you can roll back to, plus Talk for video calls when you want a call link that doesn’t depend on a third-party account.
• CalDAV/CardDAV sync for calendars and contacts across every device and client that speaks those (very ordinary, very well-supported) protocols.
• Collaborative document editing in the browser through Collabora or OnlyOffice, with multiple people editing the same document simultaneously, plus external storage mounting for S3, FTP, SMB, and WebDAV backends.
• Two-factor authentication for logins, and an activity/audit log so you can see who touched what and when, which matters the moment you need to answer “who deleted this file” honestly.

Installing Nextcloud on a VPS

The deployment path Nextcloud itself recommends today is Nextcloud All-in-One (AIO), a Docker-based setup where a single mastercontainer manages Nextcloud, the database, Collabora, and the other moving parts together, and gives you a web UI to configure the rest. It’s a meaningful improvement over hand-rolling a LEMP stack with a dozen PHP extensions, because AIO handles updates and the interdependencies between components for you.

On a fresh VPS with Docker installed, the mastercontainer starts like this:

sudo docker run \
  --init \
  --sig-proxy=false \
  --name nextcloud-aio-mastercontainer \
  --restart always \
  --publish 8080:8080 \
  --env APACHE_PORT=11000 \
  --env APACHE_IP_BINDING=127.0.0.1 \
  --volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
  --volume /var/run/docker.sock:/var/run/docker.sock:ro \
  nextcloud/all-in-one:latest

That exposes the AIO web interface on port 8080, where you set an admin passphrase and get walked through pulling and starting the Nextcloud, database, and Collabora containers. From there you point a reverse proxy (or AIO’s own built-in one) at it for the real domain and TLS certificate.

Firewall-wise, the rule of thumb is: expose only what needs to be public, and close the setup port once configuration is finished.

ufw allow 443/tcp        # HTTPS, the actual Nextcloud interface
ufw allow 8080/tcp       # AIO setup UI, restrict to your IP or close after setup
ufw deny 11000/tcp       # internal Apache port, never expose this directly
ufw enable

This is a workload that fits comfortably on a mid-tier DreamServer VPS : the mastercontainer, database, and Collabora together aren’t heavy for a small team, though you’ll want to size RAM up if you’re running Collabora for a lot of simultaneous document editors.

Configuration patterns worth knowing

Collabora vs OnlyOffice

Both plug into Nextcloud as separate services and let you co-edit Office documents in the browser. Collabora (LibreOffice’s rendering engine) tends to have better fidelity for complex ODF/OOXML formatting and is what AIO bundles by default. OnlyOffice’s UI more closely mimics Microsoft Office, and some teams find that transition easier. Neither is objectively “better,” it’s fidelity versus familiarity, and both run as their own containers alongside Nextcloud.

External storage as primary storage

For larger deployments, mounting S3-compatible object storage as the primary storage backend, rather than local disk, is a common pattern: it decouples storage growth from the VM’s disk and lets you scale storage independently of compute. This is configured per-storage in the External Storage app rather than as a wholesale replacement, so you can mix local and object storage across different folders.

Server-side encryption vs E2EE

Server-side encryption-at-rest encrypts files on disk so raw disk access doesn’t expose plaintext, useful against physical theft, but the server itself still holds the keys and can decrypt on the fly. The separate End-to-End Encryption app is stricter: specific folders where even the server operator can’t read contents, at the cost of losing features like full-text search on those folders. Default to server-side encryption and reach for E2EE only where it’s genuinely needed.

Redis for locking and caching

Nextcloud uses file locking to prevent two clients from corrupting the same file during simultaneous edits, and by default that locking, along with general caching, can fall back to slower mechanisms. Wiring in Redis for both is a well-documented performance win once you have more than a handful of concurrent users, and it’s included in the AIO stack by default.

Backing up the AIO stack

Because AIO manages its containers and volumes as a unit, backup strategy needs to account for the mastercontainer’s own backup tooling, accessible through its UI, rather than snapshotting individual containers ad hoc. Treat the whole stack, database included, as one consistent backup unit, and test a restore before you need one for real.

Where Nextcloud is not the right answer

Nextcloud is not a good fit for every case. If you’re two people who just want a shared folder that syncs, running a full server stack (web server, database, Redis, possibly Collabora) is real overhead for a problem a hosted consumer product solves with an app install and no server to think about. The AIO stack, while simpler than manual setup, is still multiple containers you’re responsible for patching and backing up, an ongoing cost, not a one-time task.

At the other end, thousands of concurrent editors and deep integration with an existing enterprise identity stack may need tooling depth a self-managed install doesn’t match out of the box (Nextcloud sells enterprise support for exactly this reason). And because the core is PHP, tuning it for very large user counts, PHP-FPM pool sizing, opcache, query performance, is its own discipline that gets fiddly without someone who’s done it before.

Alternatives we considered

• Seafile : a leaner, more narrowly-focused file sync and share tool. If all you need is fast, reliable file sync without the wider app ecosystem, Seafile’s smaller footprint is worth a look, though you give up Talk, Deck, and the built-in office suite integration.
• ownCloud : the project Nextcloud forked from in 2016. Development has diverged since, and Nextcloud has pulled ahead in app ecosystem breadth and release cadence, but ownCloud remains a legitimate, actively developed alternative if it fit your needs previously.
• Google Workspace / Microsoft 365: the honest non-self-hosted comparison. Both are more convenient out of the box, someone else handles the operations, and neither requires you to think about servers. The tradeoff is the one we opened with: your data sits on infrastructure you don’t control, in jurisdictions you don’t choose, at a per-seat price that can and does change.

So, should you run it?

If data residency, GDPR, or just not wanting to pay per-seat forever is a real concern for your organization, Nextcloud is a solid, mature answer, not a compromise. The AIO deployment path has made it considerably easier to stand up, and the app ecosystem means you’re likely replacing more than one SaaS subscription with a single self-hosted stack.

If you’d rather not run the stack yourself, that’s exactly what our Nextcloud storage hosting is for: managed Nextcloud on our own infrastructure in Bucharest, data residency handled, updates handled. If you want to run it yourself but on infrastructure that doesn’t disappear at the whim of a hyperscaler’s pricing team, a DreamServer VPS is a straightforward place to put the AIO stack, and if you’d rather hand off the ongoing patching without giving up control, our server administration service covers that gap.

This is exactly the problem centralized logging exists to solve, and it’s why a tool like Graylog has stuck around for over a decade. Graylog is an open source log management and analysis platform: it ingests logs from everything you run, stores them in a searchable index, and layers streams, dashboards, and alerting on top. The code lives at github.com/Graylog2/graylog2-server ; the core server ships under SSPL with some components under GPL, so licensing is a “check the specific component” situation rather than one blanket answer. We don’t run Graylog ourselves and don’t offer it as a managed service, but it’s a genuinely solid option worth a proper look if you’re evaluating what to self-host for logs.

What Graylog actually is

Graylog isn’t a single binary, it’s three pieces working together. The Graylog server is the brain: it receives incoming messages, applies whatever routing and processing rules you’ve configured, and serves the web UI and REST API. Under it sits OpenSearch or Elasticsearch, doing the actual heavy lifting of storing and indexing every message so you can search millions of lines in under a second, the same technology stack behind the “ELK” world. Alongside that sits MongoDB, easy to overlook but doing something different: it stores configuration and metadata, users, dashboards, stream definitions, alert conditions, index sets, everything describing how your instance is set up. Your logs go into OpenSearch; the rules about what happens to them live in MongoDB. This split is a defining trait of Graylog’s design, and it means you’re operating three services, not one.

Logs get in through inputs: Syslog (UDP or TCP), GELF (Graylog Extended Log Format, their own structured format built to carry more than a flat syslog line can), Beats (so Filebeat, Winlogbeat, and the rest of the Elastic Beats family ship straight into it), raw TCP/UDP, HTTP, and a handful of others. Whatever is already emitting logs on your infrastructure almost certainly has a way in.

Why it matters

When an incident spans multiple hosts, containers, or services, the question is never “what did server A log,” it’s “what happened, in order, across everything, in the two minutes around the failure.” Grepping per-host doesn’t answer that; a shared, searchable, time-correlated index does. It also means logs survive the machine that produced them: if a container gets OOM-killed and rescheduled, its logs are already somewhere else.

Centralized logging and metrics-based monitoring solve adjacent but different problems: metrics tell you something is wrong and roughly when, logs tell you what actually happened and why. Worth reading our Grafana post on the metrics side of that pairing. A mature setup tends to run both: Grafana for the “is something wrong right now” dashboards and alerts, Graylog for the “let’s find out exactly what happened” investigation afterward.

What you get out of the box

Streams route messages into logical buckets in real time based on rules you define, source, facility, a field value, a regex match. A stream isn’t a copy of the data, it’s a live filter letting a team or app see only its own slice of the firehose. Realistic example: route anything from your nginx inputs where response_code is 5xx into an “nginx-errors” stream, so the on-call dashboard only shows things actually broken.

Pipeline rules are where the real processing power lives, a small rule-based language for parsing, enriching, rewriting, or dropping messages as they arrive. Common pattern: pull an IP from an unstructured log line with a regex, do a GeoIP lookup, attach the country as a new field, before the message is indexed.

Extractors are the simpler sibling: regex or grok-style field extraction defined directly on an input, good for straightforward single-field pulls that don’t need the full pipeline language.

Search is where you’ll live day to day: a query language over indexed messages, with time range pickers and field statistics, backed by OpenSearch so it stays fast at real volume. Dashboards are built from saved searches and aggregations, error rate over time, top talkers by source IP, request volume by status code, arranged on one screen. Alerting runs on event definitions, conditions evaluated against your data (say, more than 50 events matching a stream in a 5-minute window) that trigger a notification, email, webhook, or other integration. Typical example: alert when the error rate in “nginx-errors” crosses a threshold in a rolling window, so you find out from Graylog instead of from a customer.

Graylog also sees a fair amount of security and SIEM-adjacent use: correlating events across systems, alerting on suspicious patterns. It’s genuinely useful there, but a full SIEM typically wants more than open source Graylog ships with, case management, curated detection content, threat intel feeds, which is part of what the commercial Graylog Security tier adds.

Installing Graylog on a VPS

Graylog publishes official Docker images for itself, OpenSearch, and MongoDB, so Compose is the fastest realistic path to a working instance:

services:
  mongodb:
    image: "mongo:6.0"
    volumes:
      - "mongo_data:/data/db"
    restart: "on-failure"

  opensearch:
    image: "opensearchproject/opensearch:2.19.1"
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g"
      - "bootstrap.memory_lock=true"
      - "discovery.type=single-node"
      - "action.auto_create_index=false"
      - "plugins.security.ssl.http.enabled=false"
      - "plugins.security.disabled=true"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - "opensearch_data:/usr/share/opensearch/data"
    restart: "on-failure"

  graylog:
    image: "graylog/graylog:6.1"
    environment:
      GRAYLOG_PASSWORD_SECRET: "changeme-to-a-long-random-string"
      GRAYLOG_ROOT_PASSWORD_SHA2: "put-a-sha256-hash-of-your-admin-password-here"
      GRAYLOG_HTTP_EXTERNAL_URI: "https://logs.example.com/"
    entrypoint: "/usr/bin/tini -- wait-for-it opensearch:9200 --  /docker-entrypoint.sh"
    ports:
      - "9000:9000/tcp"
      - "1514:1514/tcp"
      - "1514:1514/udp"
      - "12201:12201/tcp"
      - "12201:12201/udp"
    depends_on:
      - "mongodb"
      - "opensearch"
    volumes:
      - "graylog_data:/usr/share/graylog/data"
    restart: "on-failure"

volumes:
  mongo_data:
  opensearch_data:
  graylog_data:

Generate the SHA256 root password hash before you start it:

echo -n "your-real-admin-password" | sha256sum

Bring it up, wait for OpenSearch and MongoDB to finish their first boot, then hit port 9000:

docker compose up -d
docker compose logs -f graylog

Once it’s reachable, lock the ports down instead of leaving everything open. You want the web UI reachable only from your admin network or behind a TLS reverse proxy, and log-shipping ports open only to the hosts that actually send you logs:

ufw allow from 203.0.113.0/24 to any port 9000 proto tcp comment "Graylog web UI, admin network only"
ufw allow from 10.0.0.0/16 to any port 1514 proto tcp comment "Syslog TCP, internal hosts"
ufw allow from 10.0.0.0/16 to any port 1514 proto udp comment "Syslog UDP, internal hosts"
ufw allow from 10.0.0.0/16 to any port 12201 comment "GELF, internal hosts"
ufw deny 9000
ufw deny 1514
ufw deny 12201

This is exactly the kind of workload a VPS handles well: not huge on its own, but running three services means you want a machine with real, dedicated memory rather than a burstable micro instance where OpenSearch will fight you for RAM. A DreamServer VPS with a few gigabytes to spare is a reasonable start for small to medium log volume; scale the OpenSearch heap and disk as retention needs grow.

Configuration patterns worth knowing

Index rotation and retention. Graylog organizes indices into “index sets” with rotation strategies (by size or time) and retention strategies deciding when old indices close, archive, or get deleted. Get this wrong and you either burn disk on data nobody looks at, or rotate so aggressively you lose the history you needed during an incident review. Set retention deliberately per index set, not as an afterthought once disk alerts start firing.

Streams as team and application boundaries. Rather than one giant firehose everyone stares at, use streams to give each team or app its own slice, a “database” stream, a “web” stream, a “security” stream. Streams can carry their own retention settings and access permissions, so a team gets visibility into its own logs without the whole cluster’s data.

Pipeline rules versus extractors. Extractors are simpler and live on the input itself, good for a quick single-field pull with no conditional logic. Pipeline rules are the right tool once you need conditionals, multiple transformations, GeoIP or lookup-table enrichment, or routing decisions based on parsed content. Rule of thumb: if you’re writing more than one extractor to handle variations of the same message, move that logic into a pipeline rule instead.

Securing the web interface. Graylog ships its own user and role system, but beyond a single admin, plan access control deliberately: separate admin accounts from read-only viewer roles, and don’t expose port 9000 to the open internet without TLS in front of it. If you already run centralized auth elsewhere, check Graylog’s authentication provider options before adding local users.

Where Graylog is not the right answer

If you’re running one or two servers, journalctl and rotated log files with grep/awk genuinely cover most needs, and running Graylog, OpenSearch, and MongoDB just to watch logs from one box is a lot of operational overhead for very little payoff.

If your team already runs an Elastic/OpenSearch stack for other purposes (product search, analytics), adding Graylog on top means a second thing to operate against data infrastructure you already have, and it may make more sense to build log ingestion directly into what you’ve got.

Resource overhead is real: three services, each with their own memory and disk footprint, is meaningfully more than a single log aggregator binary, and OpenSearch wants real memory to stay fast. For small workloads this can be disproportionate to the problem you’re solving.

And if you actually need a SIEM with compliance-grade case management, curated detection content, and threat intelligence feeds, the open source edition alone won’t get you there; that’s the gap the commercial Graylog Security tier exists to fill.

Alternatives we considered

The Elastic Stack (elastic.co ), Elasticsearch, Logstash, Kibana, is the platform Graylog’s own storage layer is adjacent to. If you’re already invested in Elastic tooling or need Kibana’s visualization ecosystem, running the stack directly rather than through Graylog’s abstraction is reasonable, though you lose Graylog’s ops-friendly streams and pipeline UI and take on Elastic’s own licensing considerations.

Loki with Grafana (grafana.com/oss/loki ) indexes only metadata labels instead of full log content, treating log bodies as compressed, unindexed blobs, dramatically cheaper to run at scale. The tradeoff is search flexibility: broad full-text search isn’t Loki’s strong suit the way it is Graylog’s. If you’re already all-in on Grafana for metrics, Loki slots in naturally without adding a new infrastructure paradigm.

SigNoz is a newer open source observability platform bundling logs, metrics, and traces on top of ClickHouse, appealing if you want one platform covering all three signals from day one, though it’s a younger project with a smaller community and less operational history than Graylog or the Elastic stack.

So, should you run it?

If you’ve got more than a couple of servers and you’re tired of SSHing around at 3am reconstructing what happened, centralized logging earns its keep fast, and Graylog is a mature, capable way to do it: solid ingestion options, a real processing pipeline, search that stays usable at volume. Go in with eyes open about the three-service footprint, size OpenSearch properly for your log volume, and decide your retention strategy before disk usage forces the decision for you.

If you’re weighing where to run this, a DreamServer VPS gives you the dedicated resources this workload wants without over-provisioning for a small deployment, and if you’d rather not own the operational side of keeping Docker, OpenSearch heap sizes, and index retention healthy long-term, our server administration services cover exactly that kind of ongoing care.

Akvorado , the open-source flow collector built and run in production by Free (a large French ISP), exists for exactly that question. It is licensed under AGPLv3, has more than 2,300 stars on GitHub, and we run it on our own network, in our Bucharest datacenter, in front of AS57050 and our DSIX exchange. This post is the field report.

What Akvorado actually is

Akvorado is a network flow collector, enricher and visualizer. Your routers and switches export metadata about traffic (who talks to whom, on which ports, how much) via standard protocols: NetFlow, IPFIX and sFlow. Akvorado receives them, adds context, stores them in a database optimized for aggregation, and gives you a web console where you answer questions about your traffic in seconds.

The “enrichment” part is what turns a raw flow into useful information. A flow record says “IP X sent 4 GB to IP Y on interface 12”. Not very useful. Akvorado adds:

• Interface names via SNMP: interface 12 becomes “transit: telia” or “peering: franceix”, with description and speed, by querying the router over SNMP.
• Geo and ASN: IP X becomes “AS2906 Netflix” with a country, using GeoIP databases (IPinfo).
• BGP context: AS-path, communities, boundary type (internal vs external).

Out of an anonymous flow comes a readable sentence: “AS2906 Netflix sent me 4.7 Gbps through the telia transit, exiting on th2-edge1”. Exactly the kind of sentence you use to make decisions.

How it is built underneath

Akvorado is not a single binary, it is a small scale-oriented architecture, and it is worth understanding in three pieces:

• Inlet: the process that listens for flow packets (UDP) and decodes them. This is where sFlow and NetFlow from routers land.
• Orchestrator: the configuration brain, it manages the ClickHouse schema and Kafka topics, and serves configuration to the other components.
• Console: the web interface, where you, the human, ask questions and see graphs.

Behind the scenes, flows pass through a Kafka (a buffer that absorbs bursts) and land in ClickHouse, the columnar database that can aggregate billions of flow rows in milliseconds. That choice is the key: a flow analyzer lives or dies on how fast it answers “sum all my traffic over the last 24 hours, grouped by source AS”. ClickHouse is monstrously good at exactly that.

What you see in the console

The console is where Akvorado shines. You pick a few dimensions (source AS, exporter name, inbound provider, country, port) and a filter in a simple language (InIfBoundary = external), and Akvorado draws you:

• A Sankey diagram: columns left to right showing how traffic flows, from the source AS, through the connection type (transit / peering / ix), through the concrete provider (telia, cogent, franceix), to the edge router. At a glance you see what proportion of traffic comes from where and by which path it exits. It is the best picture for peering decisions you will ever see.
• Time series: the same traffic drawn over time, so you see peaks, day/night patterns and events.
• A table: the exact numbers, sortable, behind the graphs.

For an ISP or a LIR, this answers questions worth real money: “how much transit would I save if I peered directly with this AS?”, “who are my top 10 talkers?”, “is that weird 3 AM traffic a legitimate backup or the start of an attack?”.

Installing Akvorado

Akvorado is not a one-line service, precisely because it brings ClickHouse, Kafka and Redis with it. The good news: the official repo ships a complete docker compose that brings the whole stack up with one command. Clone, configure, bring up:

git clone https://github.com/akvorado/akvorado
cd akvorado/docker
cp ../config/akvorado.yaml akvorado.yaml
docker compose up -d

The compose starts ClickHouse, Kafka, Redis, plus the three Akvorado components. The console becomes available on the configured port (via the proxy in the compose by default), and the public demo at demo.akvorado.net shows you exactly what it looks like with real data, before you invest in your own setup.

The important step once it is up: tell your routers to export flows to Akvorado. On a router you configure sFlow or NetFlow toward the inlet’s IP and port. In our case, the edge routers send sFlow to Akvorado on a dedicated port, separate from the rest of our telemetry pipeline, so they do not step on each other.

As with any management console, do not expose it publicly without an authentication layer, because it reveals your network’s topology and traffic patterns. We put it behind our SSO; you, at minimum, restrict it with a firewall:

ufw allow from YOUR_OFFICE_IP to any port 8080 proto tcp
ufw deny 8080

The flow ingestion port (UDP), on the other hand, must be open toward your routers, and only toward them, so nobody can send you bogus flows.

If you are running this on a DreamServer VPS , ClickHouse will want some disk and RAM, so size it for the retention you want.

Configuration patterns worth knowing

A few things useful beyond the defaults.

Interface descriptions are everything

The power of the Sankey lives in the interface names. If your routers have clearly described interfaces (transit: X, peering: Y, ix: DSIX), Akvorado picks them up via SNMP and the graphs become instantly readable. Invest ten minutes in good descriptions on your routers and you gain months of clear reports.

Use it for peering decisions

The most valuable report you can pull: group by source AS, filter to traffic coming in via transit (not via existing peering), and sort descending. The top ASes in the list are your peering candidates, the ones where, if you connect directly at an exchange like DSIX, you move volume off paid transit onto free peering.

Retention costs disk

ClickHouse compresses excellently, but high-resolution flows over the long term still take space. Keep fine resolution short-term (the last few weeks) and aggregates long-term. Akvorado supports multi-resolution tables for exactly this.

Separate ingestion from the rest of your telemetry

If you already have an sFlow collector for something else (in our case DDoS protection), run Akvorado on a different ingestion port. A router can export the same flow to multiple collectors at once, each with its own purpose.

Where Akvorado is not the right answer

It is worth being honest about the limits.

• Not health monitoring. Akvorado tells you about traffic, not the router’s CPU, temperature or a link’s state. For that you need classic SNMP and a Grafana on top.
• Not packet capture. Flows are sampled and aggregated; you see “AS2906 sent me 4 GB”, not packet contents. For packet-level forensics you need a different tool.
• Requires hardware that exports flows. If your routers do not support NetFlow/IPFIX/sFlow, Akvorado has nothing to collect.
• ClickHouse + Kafka are not “lightweight”. It is a real stack, not a binary. On a small network it runs comfortably, but you treat it as infrastructure, with backups and tuning, not as a container you throw and forget.

Alternatives we considered

For completeness: we also looked at ntopng (excellent for real-time visibility and deep packet inspection, but less oriented toward historical analysis at scale), pmacct (the classic, extremely flexible collection engine, but no UI, you build the visualization), and Elastiflow on the Elastic stack (capable, but heavier and with commercial parts). For an ISP that specifically wants peering and traffic analysis with readable Sankey diagrams, Akvorado is the most on-target.

So, should you run it?

If you operate a network with transit and peering, or even just a router that traffic you want to understand passes through, Akvorado is worth the setup weekend. The first time you pull a Sankey and see in black and white that 40% of your paid transit comes from three ASes you could peer with for free at a local exchange, you will know it has earned a permanent place in your stack.

We run Akvorado in front of the AS57050 network, fed by our edge routers, and use it exactly for peering decisions at DSIX , our Bucharest exchange. If you want to try it on infrastructure you do not have to build first, our VPS plans are large enough to run a test ClickHouse, and our server administration service covers the install and tuning if you would rather skip the learning curve.

Either way, finally seeing who sends you your traffic is a revelation the bytes graph on your uplink will never give you. The code is on GitHub, there is a public demo you can touch right now, and you will know within an hour whether it earns a spot in front of your network.

authentik (GitHub repo , official site at goauthentik.io ) is exactly that: a self-hosted, open-source identity provider and SSO platform built to cover a wide range of authentication protocols instead of just one. It isn’t a thin proxy that slaps a login page in front of an app; it’s a full identity system, with users, groups, policies, and configurable authentication flows.

What authentik actually is

authentik doesn’t try to be just one thing: it speaks SAML, OAuth2/OpenID Connect (OIDC), LDAP, SCIM for automated account provisioning, and RADIUS for network- and VPN-level authentication. That covers the four different ways modern (and not-so-modern) systems talk about “who are you”: web apps that understand OIDC or SAML, legacy services expecting a classic LDAP directory, provisioning systems that speak SCIM, and network gear expecting RADIUS. Instead of running three or four separate tools for each of these, you run one that speaks all of them.

What really sets it apart, though, isn’t the protocol list, it’s the “flows and stages” engine. Instead of a hardcoded login screen, a fixed registration page, and a rigid password-recovery process, authentik models each of these as a configurable “flow” built from reusable “stages”: an identification stage, a password-verification stage, an MFA stage, a consent stage, and so on. You can build a different login flow for one group of users than for another, insert an extra stage only for admins, or enable self-registration (enrollment) for only certain applications. It’s flexible in the good sense of the word: you’re not stuck with the default design if you need something else.

Why it matters

The reason a centralized IdP is worth the investment is simple: every app you add without SSO is a new attack surface with its own authentication mechanism, usually weaker than you’d like (no MFA, no password-complexity policy, no centralized logging). When you centralize identity, you enforce a single MFA policy everywhere, you get one place to see who logged in where and when, and one switch to flip when someone leaves the team, instead of walking through ten apps closing accounts one by one.

To be upfront about it: DreamServer’s own internal SSO runs on Authelia , not authentik, mostly because Authelia’s lightweight single-binary/config-file model fit our stack better. That doesn’t make authentik the wrong choice, it’s a genuinely strong, more full-featured identity provider, especially if you need SAML, SCIM, RADIUS, or self-service enrollment flows that Authelia doesn’t attempt to cover. These are two tools built with different philosophies, not a winner and a runner-up.

What you get out of the box

The feature set in authentik goes well beyond “log in once, access everything”:

• Real multi-protocol support: SAML and OIDC for modern web apps, LDAP for services expecting a classic directory (plenty of legacy apps, some NAS boxes, some enterprise tools), SCIM for automated account provisioning and de-provisioning in third-party services, and RADIUS for network-level or VPN authentication. You can effectively replace four different auth systems with one.
• The flows-and-stages engine: login, enrollment (self-registration), password recovery, and other identity workflows are configurable flows, not fixed screens. You can add, remove, or reorder stages without writing code.
• A forward-auth (proxy) provider: for applications that have no native authentication of their own, authentik can sit in front of them as a forward-auth provider and gate access, conceptually similar to what Authelia or oauth2-proxy do. Useful for internal tools, dashboards, or utilities with no login system of their own.
• Solid MFA: TOTP (Google Authenticator and equivalents) plus WebAuthn/passkeys, so you can enforce passwordless or hardware-key authentication wherever you need that level of security.
• An admin UI: you manage applications, providers, users, groups, and flows from a web interface instead of hand-editing configuration files for every small change.

Under the hood, the backend is built on Python/Django plus a Go component, and it’s typically self-hosted via Docker/docker compose or Kubernetes.

Installing authentik on a VPS

A VPS is a reasonable place to run authentik: you get full control over the network and the firewall, which matters a lot when you’re putting into production an identity system that everything else now depends on. The official install path uses docker compose, with a server service, a worker service (for asynchronous tasks like sending emails or processing more complex flows), plus PostgreSQL and Redis as dependencies:

mkdir -p /opt/authentik && cd /opt/authentik

# fetch the official compose file and generate secrets into a .env file
curl -o docker-compose.yml https://goauthentik.io/docker-compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

# bring the stack up (server + worker + postgres + redis)
docker compose pull
docker compose up -d

The basic shape is simple enough: the server container serves the UI and the API, the worker processes background tasks, and Postgres and Redis hold state and the job queue. This is not a single binary, it’s a small stack of services that need to run together, and that’s worth factoring into your resource sizing and your operational expectations.

# allow only the HTTPS/HTTP traffic needed to reach authentik
ufw allow 80/tcp
ufw allow 443/tcp

# during initial setup, consider restricting access to the admin
# interface to your own IPs only (an extra rule on the admin path,
# or a reverse proxy allowlist), then relax it once MFA is enabled
# on the admin account

If you’d rather not deal with the OS, firewall, and server maintenance side of things yourself, server administration is exactly for this kind of work: you handle authentik’s configuration, we handle the rest.

Configuration patterns worth knowing

Design your first login flow instead of accepting the defaults blindly

It’s tempting to leave the default login flow exactly as it ships, but it’s worth stopping to think about which stages you actually want: identification by email or username, password verification, then mandatory MFA for everyone or just for a specific group (admins, say). Because every stage is a separate object you can reorder or condition, you can build a different flow for internal users versus external or test accounts, without duplicating any logic.

Wire the forward-auth provider in front of apps with no native login

Plenty of internal tools (dashboards, monitoring utilities, status pages) have no authentication mechanism at all, they simply assume that whoever reaches them is allowed to be there. authentik’s forward-auth provider solves exactly that: you point your reverse proxy to check the session against authentik before letting the request through, and the app behind it doesn’t even need to know an auth layer exists in front of it.

Choose OIDC, SAML, or LDAP based on what the app actually supports, not your preference

There is no universally “best” protocol, only what the target application supports. Modern, web-native apps almost always speak OIDC, less often SAML (common in enterprise or education environments). Older services or network gear often only speak LDAP. Check the target app’s documentation before you configure a new provider in authentik, not the other way around.

Enforce MFA policy from one place, not per application

One of the biggest wins of a centralized IdP is that you can enforce MFA (TOTP or WebAuthn/passkeys) at the login flow level, once, and that policy automatically applies to every application using authentik as its provider. No more configuring MFA separately in each app, with the risk of missing one and leaving a door open.

Where authentik is not the right answer

Let’s be direct: authentik is a heavier stack than it might look at first glance. Django plus a worker plus PostgreSQL plus Redis means four pieces that need to run together, get monitored, and get updated, compared to a config-file-plus-single-binary tool. If all you need is a simple forward-auth gate in front of a handful of self-hosted apps, no SAML, no SCIM, no RADIUS, the extra complexity probably isn’t worth the operational cost.

The flexibility of the flows-and-stages engine comes with its own price: the learning curve is not trivial. This isn’t a “configure it in five minutes and forget about it” system; you need to understand how stages compose and how policies interact before you’ll feel comfortable changing anything in production.

And if you already have a small homelab with a handful of apps and no real multi-protocol requirements, a simpler tool can get you 90% of the value with far less operational overhead. Not everything worth doing is worth doing with the most feature-complete tool available.

Alternatives we considered

Authelia is the most direct alternative: lighter, a single binary, configuration driven by a YAML file, built mainly for forward-auth SSO in front of a set of self-hosted apps. As mentioned above, it’s exactly what DreamServer runs internally, precisely for the operational simplicity. It doesn’t have authentik’s protocol ambitions (no native SAML, no SCIM, no RADIUS), but for a lot of use cases it covers exactly what you need without the extra ballast.

Keycloak sits at the opposite end in terms of enterprise maturity: a Java-based identity provider with protocol coverage as broad as authentik’s, but its own heavier JVM footprint and a different, more classically enterprise administration model. If you’re already deep in a Java-heavy ecosystem, or you need specific enterprise integrations, it’s worth a look.

Ory is worth mentioning for a different angle entirely: a componentized identity stack built more for developers and APIs first, where you pick the pieces you need (Kratos for identity, Hydra for OAuth2/OIDC, and so on) instead of a single monolith with an admin UI. It makes sense if you’re building your own product and want fine-grained control from code, less so if you want something ready to administer through a UI from day one.

So, should you run it?

If you need broad protocol coverage (SAML for an enterprise partner, LDAP for an aging NAS, RADIUS for VPN, OIDC for everything else), or you want configurable self-registration and password-recovery flows, or you have a pile of heterogeneous apps you want to put behind a single forward-auth gate, authentik is a solid, mature choice. If instead you want something easier to operate, with fewer moving parts, and protocol breadth isn’t a real requirement for you, consider Authelia before jumping into Django plus worker plus Postgres plus Redis.

Whichever you pick, a VPS with dedicated resources and full network control is the right place to run it, and if you’d rather not handle the system side yourself, server administration is there for exactly that.

mkcert , the tool written by Filippo Valsorda (former Go security lead at Google), solves this elegantly. It is licensed under BSD-3, it is one of the most beloved dev tools in the ecosystem, and we use it in our own workflows. This post is the field report, plus the web-interface variant we run for teams.

What mkcert actually is

mkcert does one thing and does it perfectly: it generates locally-trusted development certificates. Not self-signed certificates the browser rejects, but certificates signed by your own certificate authority (CA) that mkcert installs into your system and browser trust stores. From that moment, any certificate issued by that CA is considered valid by your machine, with no warning at all.

The subtle but crucial difference from self-signed is trust. A self-signed certificate has nobody behind it vouching for it, so the browser complains. An mkcert certificate is signed by your local CA, and your local CA is explicitly trusted on your machine because mkcert registered it there. It is the same mechanism by which Let’s Encrypt or any public CA works, just at the scale of your machine, not the internet.

How it works underneath

The flow has two steps, and that is all you need to understand:

1. mkcert -install: creates a CA key pair (once, on the first run) and installs it into the relevant trust stores, the operating system, plus Firefox and Chrome via the NSS database. From this moment, your machine trusts anything this CA signs.
2. mkcert example.test localhost 127.0.0.1 ::1: issues a certificate valid for exactly those names and IPs, signed by your local CA. It writes two files, the certificate and the private key, which you hand to your local server.

You put the certificate into nginx, into your Node app, into anything, and https://example.test works with the green padlock, without a single warning. Two steps, zero configuration, zero PKI theory to learn.

What you get out of the box

mkcert is minimalist by design, but it covers everything you need:

• Multiple names on one certificate: domains, subdomains, localhost, IP addresses (IPv4 and IPv6), all in a single certificate.
• Wildcard certificates: mkcert "*.example.test" covers all subdomains at once.
• Cross-platform: macOS, Linux and Windows, installable via Homebrew, distro packages, Chocolatey/Scoop or a direct binary.
• Multiple trust stores: system, Firefox, Chrome, Java, NSS, all updated by -install.
• Formats: PEM by default, plus PKCS#12 (.p12) for tools that require it.
• S/MIME certificates: for email signing in development.

What it does not do, by design: mkcert is not for production. Its CA is only trusted on the machines where you manually installed it. A random visitor from the internet will see the same red screen, because their browser does not know your CA. For public certificates you need a public CA (Let’s Encrypt, Google Trust Services), and mkcert does not even try to compete there. It is the tool for development, labs and internal networks, exactly where it shines.

Installing and your first certificate

On Linux, the simplest way is through the package manager or the direct binary:

# Debian/Ubuntu
sudo apt install libnss3-tools
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo mv mkcert-v*-linux-amd64 /usr/local/bin/mkcert

# install the local CA (once)
mkcert -install

# issue a certificate for your project
mkcert example.test "*.example.test" localhost 127.0.0.1 ::1

The second command writes example.test+4.pem (the certificate) and example.test+4-key.pem (the key). You point your server config at them and you are done. In nginx, for example:

server {
    listen 443 ssl;
    server_name example.test;
    ssl_certificate     /path/example.test+4.pem;
    ssl_certificate_key /path/example.test+4-key.pem;
}

libnss3-tools matters on Linux: without it, mkcert cannot install the CA into Firefox and Chrome, only into the system trust store. With it, all browsers trust it from the first go.

mkcert for a team: the web interface

mkcert on the command line is perfect for a single developer on their machine. But when you have a team or an internal lab where several people need certificates for internal services, distributing keys by hand over Slack gets ugly fast. This is where mkcert Web UI comes in, a web layer over mkcert that we run for exactly this need.

It gives you a dashboard where you issue certificates for any domain and IP without touching the terminal, in PEM, CRT or PFX formats. It also brings things useful for a team:

• Expiry monitoring with email notifications before a certificate expires.
• SCEP, the automatic device enrollment protocol.
• Authentication, basic auth or SSO through OpenID Connect.
• Dark/light theme and a clean UI.

We keep it behind our SSO, so only our people can issue certificates from the internal CA. One hygiene step: the CA is a trust key, treat it as a secret. Anyone with the CA’s private key can issue certificates your machines will believe. Do not expose it, do not put it in Git, and restrict who reaches the interface.

Configuration patterns worth knowing

A few things useful beyond the defaults.

Distribute the CA, not the certificates

If you have a team, do not issue and distribute certificates one by one. Distribute the public CA once (mkcert -CAROOT shows you where it is), install it on the team’s machines, and from there each person issues whatever certificates they want, all trusted on all machines. One CA, many certificates.

Use a .test or .localhost domain

For development, use reserved TLDs like .test or .localhost, which will never exist publicly. You avoid collisions with real domains and it is clear from the name that it is a development environment.

Do not bake the CA into public Docker images

The temptation is to put the CA into a development image so it is “ready”. Do not do it for images that end up in a public registry, you have published a CA key. Mount it at runtime from a volume, do not bake it into the image.

PKCS#12 for stubborn tools

Some tools (Java, certain clients) do not want PEM but .p12. mkcert outputs the format directly with mkcert -pkcs12 example.test, without wrestling with openssl incantations.

Where mkcert is not the right answer

It is worth being honest about the limits.

• Not for production. We repeat it because it is the most common mistake: the mkcert CA is only trusted where you manually installed it. A public site needs a certificate from a public CA.
• Not certificate management at scale. For automatically rotating hundreds of production certificates you need ACME (Let’s Encrypt, Google Trust Services), not mkcert.
• The local CA is a risk surface. If someone steals your CA key and installs it without your knowledge, they can issue certificates you trust. Treat -CAROOT with care.
• Does not solve trust between foreign machines. Two computers that do not have the same CA installed will not trust each other’s certificates. It is a local-first tool by definition.

Alternatives we considered

For completeness: we also looked at plain openssl (you can do everything mkcert does, but with ten cryptic commands and good odds of getting a field wrong), Caddy (which automatically issues locally-trusted certificates for development, excellent if you use it as your server anyway), and step-ca from Smallstep (a full private CA with ACME, far more capable but also far heavier, right when you actually want a serious internal PKI). For “I want local HTTPS that works now, without becoming a PKI expert”, mkcert is the most on-target.

So, should you run it?

If you develop any local web service and you are tired of the red screen, mkcert is worth the five minutes to install. The first time https://your-project.test opens with the green padlock, without a single warning, without having learned a word of PKI theory, you will understand why it is one of the most beloved dev tools in the ecosystem.

If you have a team or an internal lab, add mkcert Web UI behind an SSO and distribute the CA once to all machines, and issuing certificates becomes a click. We run it exactly like that, for our internal services. If you want to put it on infrastructure you do not have to build first, our VPS plans are perfect for a small internal certificate server, and our server administration service covers the setup and SSO integration if you would rather skip the learning curve.

Either way, an evening with no red browser screens is a better evening. The code is on GitHub, the install is one command, and you will know within five minutes whether it earns a spot in your workflow.

Grafana , the open-source visualization layer from Grafana Labs , is effectively the de facto standard for the “single pane of glass” that infrastructure teams stare at. As of version 13.0 (released April 2026) it is licensed under AGPLv3, has tens of thousands of stars on GitHub, and runs on anything from a home Raspberry Pi to fleets of thousands of servers. We have been running it in front of our own infrastructure, in our Bucharest datacenter, for years. This post is the field report.

What Grafana actually is

First confusion to clear up: Grafana is not a complete monitoring system, it is the visualization and alerting layer on top of one. It does not collect metrics itself, it does not store time series, and it has no agent crawling your servers. Grafana connects to a data source that already holds the numbers, queries it, and draws it into dashboards.

That is the single most important thing to understand before anything else: Grafana needs a data backend behind it. The most common pairing is Grafana plus Prometheus or, as we run it, VictoriaMetrics (a drop-in Prometheus-compatible store that is several times more disk-efficient). Prometheus/VictoriaMetrics scrape metrics from exporters (node_exporter for hosts, cadvisor for containers, SNMP exporters for switches), store them, and Grafana reads them back through PromQL and turns them into graphs.

Architecturally, Grafana is a service written in Go with a TypeScript/React frontend, and it keeps its own configuration (dashboards, users, data sources, alert rules) in a database (SQLite by default, or PostgreSQL/MySQL for large setups). Do not confuse that database with your monitoring data: the Grafana database only holds metadata, the time series live in the data source.

Why the data-source model matters

Grafana’s real power is that it decouples visualization from storage. The same dashboard can combine, on one screen, panels that pull from three different sources: metrics from VictoriaMetrics, logs from Loki , and a direct query into an application PostgreSQL. You are not locked to a single data vendor. When someone tells you “the app was slow at 14:32”, you put a latency panel next to an error-log panel next to a CPU panel, all lined up on the same time axis, and you see the correlation at a glance.

Grafana supports dozens of native data sources: Prometheus, VictoriaMetrics, Loki, Tempo (traces), InfluxDB, Graphite, Elasticsearch, PostgreSQL, MySQL, CloudWatch and many more via plugins. In practice you pick the metrics backend by scale, and Grafana stays constant on top.

What you get out of the box

The open-source edition (Grafana OSS, which is what we are talking about; there is also a commercial Enterprise edition, more on it below) ships with everything you need for serious observability:

• Dashboards and panels of every kind: time-series, gauge, stat, table, heatmap, bar chart, state timeline. Each panel is a query plus a visual representation.
• Unified alerting: alert rules that evaluate a query on an interval and fire when a threshold is crossed, with contact points (email, Slack, Telegram, webhook, PagerDuty) and notification policies that route the alerts.
• Explore, an ad-hoc query mode for when you want to dig into PromQL or LogQL without building a dashboard, exactly what you need in the middle of an incident.
• Provisioning as-code: data sources, dashboards and alert rules can be defined in YAML/JSON files version-controlled in Git, not just clicked into the UI (more on this below, it is the single best thing to do).
• Variables and templating: one dashboard with a $host dropdown that shows any server in the fleet, instead of one dashboard per machine.
• Transformations: joins, calculations and filters on query results, right in the panel, without touching the data source.
• Flexible authentication: native login, OAuth (Google, GitHub, generic OIDC), LDAP, or reverse-proxy auth (how we do it, with a header injected by an SSO layer in front).
• Annotations: markers on the time axis for deploys, incidents or maintenance windows, so you immediately see “aha, the graph jumped exactly when we shipped”.

What it does not do: Grafana does not collect metrics (that is the exporters plus Prometheus/VictoriaMetrics), does not aggregate logs itself (that is Loki or Elasticsearch), and does not replace an ITIL system with ticketing and acknowledgement. It is the visualization and alerting layer, and it is the best at it.

Installing Grafana on a VPS

Grafana is a single Go binary, so installing it is easy. The cleanest way on a modern server is via Docker, alongside a metrics backend. A minimal docker compose example, Grafana plus VictoriaMetrics:

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:latest
    command: ["--retentionPeriod=12", "--storageDataPath=/vmdata"]
    volumes:
      - ./vmdata:/vmdata

  grafana:
    image: grafana/grafana-oss:13.0.0
    ports:
      - "3000:3000"
    volumes:
      - ./grafana:/var/lib/grafana
      - ./provisioning:/etc/grafana/provisioning
    environment:
      GF_SECURITY_ADMIN_PASSWORD: "change-me"

Bring the stack up with docker compose up -d, then the UI is at http://<your-server-ip>:3000/ with user admin and the password you set. The first thing you do: wire up the data source. Not by clicking, but through provisioning (see below) so it is reproducible.

As with any management interface, port 3000 should not be exposed to the whole world without a protection layer. Either put it behind a reverse proxy with TLS and authentication, or restrict it to your IPs with a firewall rule:

ufw allow from YOUR_OFFICE_IP to any port 3000 proto tcp
ufw deny 3000

If you are running this on a DreamServer VPS , put the same rule in your provider’s network firewall too, do not rely on host-level rules alone for management interfaces.

Dashboards-as-code: the single best thing you can do

The temptation at first is to build everything in the UI: add the data source with clicks, make dashboards by hand, set alerts from the interface. It works, but you have built a black box you cannot recreate if the server dies. The clean solution is provisioning, where everything about the configuration lives in files version-controlled in Git.

The data source, a YAML file:

# /etc/grafana/provisioning/datasources/vm.yaml
apiVersion: 1
datasources:
  - name: VictoriaMetrics
    type: prometheus
    access: proxy
    url: http://victoriametrics:8428
    isDefault: true

A dashboard provider that auto-loads any JSON from a folder:

# /etc/grafana/provisioning/dashboards/default.yaml
apiVersion: 1
providers:
  - name: DreamServer
    folder: DreamServer
    type: file
    options:
      path: /var/lib/grafana/dashboards

And the dashboards themselves are JSON files in that folder. You do not have to write them from scratch: the Grafana community has thousands of ready-made dashboards at grafana.com/dashboards . A few we use and recommend:

• Node Exporter Full (ID 1860): everything you could want about a Linux host, CPU/RAM/disk/network, at an absurd level of detail.
• Ceph Cluster: the health of a Ceph storage cluster.
• A container dashboard via cAdvisor, so you see which container is eating the CPU, not just that the host is loaded.

You import them once, save them as JSON in the provisioned folder, and from there they are in Git. On the next deploy, a fresh Grafana comes up with all the dashboards already there. That is the difference between “I have a Grafana” and “I have an observability platform I can rebuild in a minute”.

Configuration patterns worth knowing

A few things we found genuinely useful beyond the defaults.

Reverse-proxy authentication

Grafana’s native login is fine for a single person, but if you already run company SSO, disable it and let a reverse proxy do the authentication, injecting the user into a header:

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
auto_sign_up = true

That way people log in once, through the company identity, and Grafana creates them automatically on first access. When someone leaves, you disable them in the SSO and their access to the dashboards vanishes.

One dashboard with variables, not fifty dashboards

Do not build one dashboard per server. Build a single one with a $host variable populated from a query (label_values(node_uname_info, instance)) and a dropdown that swaps the whole page between machines. Add a new server to the fleet and it shows up in the dropdown on its own. Less to maintain, easier to compare two nodes.

Alert on symptoms, not causes

The temptation is to put an alert on every metric. The result is noise and alerts you learn to ignore. Alert on what hurts the user: a disk nearly full, a service that stopped responding, latency that jumped, an error rate that is climbing. CPU at 90% is not a problem if the app responds fine. Keep the number of alerts small enough that you wake up for every one.

Send alerts somewhere you actually see them

An email contact point is the minimum; a dedicated Slack/Telegram channel is better, because alerts do not drown in an inbox. Configure failure with a threshold of a few consecutive evaluations so it does not scream at the first transient spike, and enable the resolved notification so you know when it settled on its own.

Read Explore mode before building panels

When you investigate something new, do not build a dashboard. Open Explore, write ad-hoc PromQL queries, see which metrics exist and what they look like. Only after you have found the query that says something do you put it in a panel. Explore is where you understand the data; the dashboard is where you present it.

Where Grafana is not the right answer

It is worth being honest about the limits.

• Not a database. Without a metrics backend (Prometheus, VictoriaMetrics, InfluxDB) there is nothing to visualize. Grafana alone monitors nothing; it is the top half of the stack.
• Does not collect logs itself. For logs you need Loki or Elasticsearch behind it. Grafana draws them, but something else gathers them.
• Not a replacement for a classic auto-discovery monitoring system. Tools like Checkmk or Zabbix discover services on their own, keep hardware/software inventory, and have an ITIL acknowledgement workflow. Grafana is complementary: graphs and correlation, not ticketing. We run it in parallel with Checkmk without them stepping on each other.
• AGPLv3 matters if you modify and offer it as a service. For internal use, the license does not touch you. But if you modify Grafana and offer it as a network service, you are obligated to publish your changes. For the vast majority of cases, irrelevant.
• Enterprise features are closed. Scheduled PDF reports, granular RBAC, LDAP team sync and a few enterprise data-source plugins (Splunk, Oracle, ServiceNow) are in the commercial edition. The OSS edition is generous, but if you need reports emailed automatically to management, plan accordingly.

Alternatives we considered

For completeness: we also looked at Kibana (excellent if you live in the Elasticsearch ecosystem, weaker outside it), Netdata (sensational for instant per-node visibility with zero configuration, but less suited as a centralized fleet pane), Zabbix and Checkmk (complete monitoring systems with auto-discovery and alerting, but with more rigid graphing), and Perses (a newer, fully open-source, dashboard-as-code-first project, worth watching).

Grafana ended up being the cleanest fit for “I want a single pane over which I can put any data source and correlate everything, without locking into a vendor”. Your weights might be different.

So, should you run it?

If you manage more than a few servers and you are tired of ssh-ing into each one when something goes wrong, Grafana plus a metrics backend (VictoriaMetrics is our pick) is worth a Sunday afternoon. The install is fast, community dashboards give you value in five minutes, and the first time a graph shows you the cause of an incident before you even manage to panic, you will know it has earned a permanent place in your stack.

If you run it in production, keep the configuration in Git through provisioning, put it behind SSO, and treat its database (SQLite or Postgres) as infrastructure with backups. Dashboards rebuild from JSON in a minute; what you would actually lose are the users, the alerts and the annotation history.

We run Grafana over VictoriaMetrics for our entire fleet, with dashboards provisioned from Git and alerts on email, and we recommend it to any customer who asks how to see their infrastructure. If you want to try it on infrastructure you do not have to build first, our VPS plans start at small enough sizes to make the experiment cheap, and our server administration service covers the install, the metrics backend and tuning if you would rather skip the learning curve.

Either way, putting a dashboard in front of yourself is a better way to spend an evening than another top on another server. The code is on GitHub, a docker compose stack has you running in five minutes, and you will know within an hour whether it earns a spot in front of your infrastructure.

Wazuh (repo at github.com/wazuh/wazuh , official site wazuh.com ) is built for exactly that jump: an open-source platform, licensed under GPLv2, that combines XDR (Extended Detection and Response) with SIEM (Security Information and Event Management) in a single stack. For organizations that need centralized log analysis and file integrity monitoring across a fleet of servers, Wazuh is one of the strongest open-source options available today, not because it’s the only one, but because it realistically covers the whole cycle: telemetry collection, detection, correlation against known frameworks, alerting, and compliance reporting.

What Wazuh actually is

At its core, Wazuh works with lightweight agents installed on endpoints and servers, which collect telemetry (system and application logs, system calls, file changes, software inventory) and forward it to a central Wazuh server. There, the data gets decoded, matched against a ruleset, and turned into meaningful alerts instead of raw lines of text. Around that core sits an indexer, built on OpenSearch, which stores and indexes the full data volume, and a dashboard, built on OpenSearch Dashboards, where you search, visualize, and configure alerting.

Why centralizing security telemetry beats eyeballing individual server logs

When you have a single server, reading logs by hand is a perfectly reasonable approach. The problem shows up at scale: an attacker moving laterally across a network leaves fragmented traces on multiple machines, traces that look harmless in isolation but make sense only once lined up on a single timeline. Log rotation deletes evidence before you notice it, and an auditor asking for proof that you monitor a configuration file’s integrity won’t settle for “I check every now and then.” Centralizing security telemetry gives you one ruleset applied consistently, one timeline of events, and one place where alerts show up, regardless of which of your 20 or 200 machines something happened on.

From OSSEC to a full XDR/SIEM stack

Wazuh has roots in the OSSEC lineage, an older tool focused almost entirely on log analysis and rule-based intrusion detection, running as a fairly simple binary alongside an agent. Real security needs at an organization don’t stop at “alert me when a suspicious word shows up in a log,” though: you also need correlation against known vulnerabilities, compliance reporting, a searchable dashboard for the security team, and a way to place each detection in the context of a known attack tactic or technique. That’s the need that produced today’s stack: Wazuh grew from a log-based detection engine into a full XDR/SIEM platform, with its own indexer and dashboard.

What you get out of the box

A base Wazuh install isn’t a single feature, it’s a bundle of capabilities that, taken together, cover most of an operational security program’s requirements:

• Agents for endpoints and servers: lightweight processes installed on every monitored machine, collecting logs, system events, and inventory data.
• File Integrity Monitoring (FIM): tracking changes to content, permissions, ownership, and attributes for the files and directories you flag as important.
• Log analysis engine: decoders and rules that turn raw text from logs into classified, prioritized events and alerts.
• Intrusion and rootkit detection: looking for hidden files, cloaked processes, unregistered network listeners, and inconsistencies in system call responses.
• Vulnerability detection: the software inventory collected by agents is checked against continuously updated CVE databases, so you find out which installed packages have known vulnerabilities.
• Configuration assessment and compliance: periodic scans that compare system settings against hardening guides, mapped to standards like PCI DSS, GDPR, and HIPAA.
• MITRE ATT&CK mapping: relevant detections can be tied to a known attack tactic or technique, giving you immediate context instead of just an alert title.
• Indexer and dashboard: OpenSearch for storage and search, plus a web interface for visualization and alerting configuration.

Not every organization needs all of this at once, but Wazuh’s real value comes from these pieces working together, rather than as separate tools you have to glue together yourself.

Installing Wazuh on a VPS

Wazuh isn’t a single binary you start and forget. It’s a multi-component stack (server, indexer, dashboard) plus agents deployed separately on every monitored machine. The most practical way to stand it up on a VPS is a docker compose setup that starts the three central services in an isolated network:

git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.0
cd wazuh-docker/single-node

# generate the internal certificates used between components
docker compose -f generate-indexer-certs.yml run --rm generator

# start the stack: wazuh-manager, wazuh-indexer, wazuh-dashboard
docker compose up -d

# check that every container is healthy
docker compose ps

That brings up the central server, the indexer, and the dashboard on the same VPS. The agent, however, gets installed separately, on every machine you want to monitor (including, if you want, the VPS running the server itself), configured to report to the Wazuh server’s IP address.

Once the stack is up, you still need to open the right ports in the firewall. The dashboard is served over HTTPS, and the server listens on separate ports for agent registration and ongoing communication:

# access to the web dashboard (HTTPS)
sudo ufw allow 443/tcp

# registration of new agents
sudo ufw allow 1515/tcp

# ongoing agent -> server communication
sudo ufw allow 1514/tcp

# Wazuh server API (optional, for automation)
sudo ufw allow 55000/tcp

Because this is a multi-service stack, sizing the VPS matters a lot more than it would for a simple command-line utility: the indexer, being built on OpenSearch, wants real memory, and CPU and disk usage scale directly with the number of agents and the volume of ingested logs. A VPS undersized for a few dozen agents quickly becomes the point where the dashboard starts lagging and indexing falls behind.

Configuration patterns worth knowing

Tuning FIM to watch the right paths, not the whole filesystem

The initial temptation is to point File Integrity Monitoring at everything: /etc, /usr/bin, /var/www, maybe even all of /home. The result is an alert volume where the real signal (an unexpected change to a critical configuration file) gets buried in normal noise (a deploy rewriting dozens of files every day). It’s worth starting narrow: system configuration paths, critical binaries, authentication files, expanding the list gradually as you learn what’s normal in your environment.

Picking and writing decoders and rules for your actual log sources

Wazuh ships with a generous set of decoders and rules for common software (nginx, sshd, base system logs), but any internal application or less common stack needs its own decoders to turn logs into useful events. The time invested here is what separates a SIEM that actually tells you something concrete from one that just archives text nobody reads.

Using compliance mappings as a starting checklist, not a certification

The mappings to PCI DSS, GDPR, or HIPAA are useful as an initial checklist and as evidence for auditors that you have an active monitoring process, but they don’t replace an actual compliance audit performed by someone qualified. Treat them as a solid starting point, not a permanently checked box.

Sizing the indexer for your real log volume and retention needs

OpenSearch, the engine behind the indexer, is the component that feels the growth in agent count and log volume the hardest. The retention period you choose (how many days or months you keep indexed data) multiplied by daily event volume gives you your disk requirement directly, and searches over a poorly sharded, large dataset get slow fast. Think about retention and sharding from day one, not after the indexer starts gasping for air.

Where Wazuh is not the right answer

Honestly, Wazuh is overkill for a single small VPS or a handful of personal projects. A stack with a server, an indexer, and a dashboard, each with its own memory and CPU requirements, is a lot heavier than a single tool quietly running in the background. If all you have is one machine and you just want to know when someone’s trying to brute-force SSH, there are much lighter tools built for exactly that need.

Wazuh’s real value only shows up once you have enough hosts and log volume to justify a centralized platform, and an actual security or compliance need that requires proof, not just “I check the logs sometimes.” On top of that, a SIEM doesn’t run itself: it needs ongoing rule tuning and someone who actually looks at the alerts, or it turns into exactly the kind of noise you install and then ignore. A Wazuh instance set up and forgotten is worse than no Wazuh at all, because it gives a false sense of security.

Alternatives we considered

Wazuh isn’t the only option, and the right choice depends a lot on scale and actual need:

• CrowdSec : a behavior-based IPS, much lighter than Wazuh, well suited to smaller setups where you want automatic detection and blocking of common attacks (brute-force, scanning) without standing up a full analysis and indexing stack.
• Elastic Stack / Elastic Security : a DIY SIEM approach, where you build the pieces yourself (ingestion, indexing, rules, visualization) using Elastic’s components. More flexibility, but also more integration work.
• Graylog : a lighter-weight alternative, focused on log management rather than a full security bundle with FIM, vulnerability detection, and compliance mappings included from the start.

If the real need is automatically blocking common attacks on a few servers, CrowdSec is probably enough. If you already have a compliance requirement and a serious fleet of servers, Wazuh gives you more out of the box.

So, should you run it?

Wazuh is the right tool once you already have real infrastructure to monitor, an actual security or compliance requirement, and the resources (human and server) to keep it tuned and actually watched. It’s not the right tool for a hobby VPS or a two-machine personal project, where the weight of the stack doesn’t pay for itself.

If you’re in the camp where Wazuh genuinely makes sense, the first practical step is a VPS properly sized for the indexer and server, not leftover resources scraped together from other services. And because this is a stack that needs continuous tuning, not just an initial install, professional server administration is often worth investing in from day one, instead of discovering mid-incident that nobody’s looked at the dashboard in three months.

CrowdSec (source on GitHub at https://github.com/crowdsecurity/crowdsec , project site at https://crowdsec.net , MIT licensed) is what you get when you take the fail2ban idea and add the one ingredient it always lacked: a crowd. It’s a free, open-source intrusion prevention system written in Go that parses your logs, runs behavior-based scenarios against them to spot bruteforce attempts, scanning, and known exploitation patterns, and then, if you opt in, shares what it learns with every other CrowdSec instance on the internet. We run CrowdSec in front of our own services here at DreamServer, paired with Traefik as the reverse proxy and its CrowdSec bouncer, to block malicious IPs at the edge before they reach our applications. It’s the kind of component that quietly does its job in the background, exactly what you want from anything sitting in the security path.

What CrowdSec actually is

Structurally, CrowdSec splits the job into pieces that talk to each other over a small local API. The crowdsec agent does the log parsing: it tails whatever files you point it at (Nginx access logs, Traefik logs, auth.log for SSH, application logs, anything with a timestamp and an IP in it), normalizes each line through a parser, and feeds the result into detection “scenarios.” A scenario is a small, declarative rule describing a pattern of bad behavior over time: ten failed SSH logins from one IP in two minutes, a burst of 404s that looks like directory bruteforcing, a request matching a known CVE payload signature. When a scenario fires, it produces a “decision,” which is really just a statement: ban, or captcha, this IP, for this long, for this reason.

The important detail: CrowdSec itself never blocks anything. The LAPI stores decisions in a database (SQLite by default), and separate “bouncers” enforce them: a firewall bouncer driving iptables or nftables, an Nginx bouncer, a Traefik bouncer/plugin, a Cloudflare bouncer pushing bans into Cloudflare’s rules, and others for different chokepoints. The separation is deliberate: detection and enforcement are different concerns, so you can run detection on a box that has no business touching the firewall, or enforce the same decision at multiple layers at once.

Why crowdsourced detection beats fighting alone

What actually makes CrowdSec more than “fail2ban with better YAML” is the community blocklist. Every participating instance can, if you opt in, report the IPs it confirms as attackers back to a central service, and in return receive a stream of IPs other instances have already flagged. In practice, an address that started hammering someone else’s SSH port in Germany this morning can already be blocked on your server in Bucharest before it ever sends you a single packet. That’s a fundamentally different posture than fail2ban’s local-only model: instead of every server independently rediscovering the same handful of scanning botnets, the discovery happens once, somewhere, and the mitigation propagates. It doesn’t replace local detection, your own scenarios still catch things specific to your traffic, but it turns thousands of otherwise-isolated servers into something closer to a shared sensor network, a genuinely different security model, not just a marketing angle on an old idea.

What you get out of the box

The core install gives you a fairly complete toolkit without much extra work:

• A log parsing and detection engine (the crowdsec agent) watching multiple log sources at once.
• A curated catalog of parsers, scenarios, and “collections” at the Hub, hub.crowdsec.net, contributed by CrowdSec and the community, covering common stacks like Linux, SSH, Nginx, Traefik, and WordPress.
• The Local API (LAPI), the source of truth for decisions and what bouncers query.
• An ecosystem of bouncers for different enforcement points: host firewalls via iptables/nftables, Nginx, Traefik, Cloudflare, and more.
• The opt-in community blocklist, really the whole point of the project’s name.
• cscli, the command-line tool for installing collections, inspecting decisions, and managing bouncers without hand-editing YAML for every change.

There’s also an optional cloud Console for visibility across a fleet, but nothing about the engine or the bouncers requires it. It’s entirely usable fully self-hosted and offline, which matters if “send our security telemetry to a third party” is a line you don’t want to cross.

Installing CrowdSec on a VPS

A minimal Docker setup looks roughly like this: the CrowdSec container reads your logs and runs its own LAPI, and a bouncer container queries that LAPI to know what to block.

# Run the CrowdSec engine, mounting the logs it should watch
docker run -d \
  --name crowdsec \
  --restart unless-stopped \
  -v /var/log:/var/log:ro \
  -v /etc/crowdsec:/etc/crowdsec \
  -v crowdsec-db:/var/lib/crowdsec/data \
  -p 8080:8080 \
  crowdsecurity/crowdsec

# Install collections matching your stack (SSH + generic Linux)
docker exec -it crowdsec cscli collections install crowdsecurity/sshd
docker exec -it crowdsec cscli collections install crowdsecurity/linux

# Register a bouncer, then start the firewall bouncer with its key
docker exec -it crowdsec cscli bouncers add firewall-bouncer
docker run -d \
  --name crowdsec-firewall-bouncer \
  --restart unless-stopped \
  --network host \
  --cap-add=NET_ADMIN \
  -e BOUNCER_KEY_FILE=/etc/crowdsec/bouncer.key \
  -v /etc/crowdsec/bouncer.key:/etc/crowdsec/bouncer.key:ro \
  crowdsecurity/cs-firewall-bouncer

If you’re fronting web traffic with Traefik instead of, or alongside, the host firewall, the Traefik CrowdSec bouncer plugin talks to the same LAPI and rejects requests at the reverse proxy layer, exactly the combination we run in front of our own services.

On the host firewall side, keep it simple: CrowdSec’s own bouncer handles IP-level blocking dynamically, so your static rules just need to stay out of the way for legitimate traffic:

# ufw note: keep the baseline permissive for the ports you actually serve,
# and let the CrowdSec bouncer handle dynamic IP blocking on top of it
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

If you’re setting this up on a fresh box, our VPS plans give you full root access, so nothing here needs any workarounds; you configure CrowdSec exactly like on any Linux server you own.

Configuration patterns worth knowing

Choosing collections for your actual stack

Don’t install everything the Hub offers just because it’s there. Pull the collections matching what’s actually running: crowdsecurity/sshd and crowdsecurity/linux for basically any server, crowdsecurity/nginx or crowdsecurity/traefik for your reverse proxy, crowdsecurity/wordpress if you host WordPress. Extra collections just run extra parsers against logs they’ll never match, adding noise and slowing troubleshooting later.

Whitelisting your own traffic before it bites you

The single most common CrowdSec support request is “I locked myself out.” Scenarios don’t know the difference between an attacker bruteforcing SSH and a developer who fat-fingered their password four times in a row. Before you go live, add your office and home IPs, your CI runners, and any monitoring service hitting your endpoints on a schedule, to a whitelist parser. It takes two minutes and saves an awkward out-of-band recovery later.

Wiring a bouncer that actually enforces decisions

This is the step people skip, and it’s the one that matters. A decision that nothing enforces is a log entry, not a defense. Whether you use the firewall bouncer, the Nginx bouncer, or the Traefik plugin, verify with cscli decisions list that bans are being created, then verify separately that the bouncer is actually querying the LAPI and dropping traffic. Detection without enforcement is a security theater prop.

Deciding on the community blocklist and the Console

Opting into the shared blocklist is where CrowdSec earns its name, and for most people it’s a clear win: you get ahead of IPs before they hit you. It does mean your instance reports confirmed attacker IPs upstream, so if that data-sharing model doesn’t fit your compliance posture, run CrowdSec entirely locally and skip it, you just lose the network effect. The Console is a separate, genuinely optional layer for multi-machine visibility; the engine works identically with or without it.

Where CrowdSec is not the right answer

It’s worth being honest about the edges. CrowdSec is not a SIEM: no long-term log retention, no correlation across event types, no compliance reporting, it’s a detection-and-decision engine focused on network-level bad behavior. It’s not a WAF replacement either; deep application-layer inspection, like recognizing a SQL injection attempt inside a specific POST body, is a different problem than “this IP is scanning.” It depends entirely on bouncers being deployed, an instance with no bouncer attached is just an expensive log reader. It also depends on decent parsers existing for your exact log format; an unusual application log with no matching Hub parser gets nothing out of the box until you write one. And none of this substitutes for patching: it can slow down a scanner probing a known CVE, but an unpatched vulnerability still exposes you to a patient attacker who never trips the bruteforce or scanning scenarios at all.

Alternatives we considered

fail2ban is the obvious comparison, and still a perfectly reasonable choice for a single box where you don’t need shared threat intelligence: simpler, no LAPI, no bouncer concept, just log-watching and local bans. What it doesn’t give you is CrowdSec’s network effect or its Hub ecosystem of maintained scenarios.

Wazuh sits at a completely different weight class: a full XDR/SIEM platform with file integrity monitoring, vulnerability detection, compliance reporting, and centralized log management across a fleet. If you need SIEM-grade visibility and the operational budget to run it, Wazuh is a serious tool; for a handful of VPS instances it’s usually more infrastructure than the problem calls for.

ModSecurity operates at a different layer entirely: an application-layer WAF inspecting HTTP request and response bodies against rule sets like OWASP CRS, catching SQL injection and XSS payloads inside the request itself. CrowdSec is behavior-based and network-focused; ModSecurity is content-based and application-focused. Complementary rather than competing, running both isn’t redundant.

So, should you run it?

If your current defense is either nothing or a lonely fail2ban jail rediscovering the same botnets since 2019, CrowdSec is a straightforward upgrade: free, open source, and genuinely useful the moment you install a couple of collections and wire up one bouncer. The catch is that it only does anything if you finish the job: pick the right collections, whitelist your own traffic, and deploy a bouncer that actually enforces what it decides. Start with a VPS you control end-to-end (our VPS plans give you root access to set this up exactly as described above), and if you’d rather someone else own the hardening, patching, and monitoring entirely, that’s what our server administration service is for.

NetBox (github.com/netbox-community/netbox , netboxlabs.com , Apache-2.0 licensed) solves exactly this problem: it’s the de facto open-source tool for DCIM (data center infrastructure management) and IPAM (IP address management), combined into a single, queryable, API-driven system. This isn’t a passing technical curiosity for us: NetBox is DreamServer’s own CMDB and IPAM, the actual source of truth that our Ansible-based automation reads from, and writes to, every time we provision something. When we spin up a new virtual machine across our Proxmox virtualization clusters, IP allocation and device registration happen through NetBox, not inside someone’s head or a local spreadsheet. Before NetBox, infrastructure knowledge was tribal and spreadsheets were already stale by the time you opened them. Now it’s queryable, API-driven, and our automation genuinely reads from it.

What NetBox actually is

NetBox is a Django web application backed by PostgreSQL that models both the physical and logical layers of your infrastructure: sites, racks, devices, cabling, power, IP addresses, prefixes, VLANs, VRFs, provider circuits, autonomous system numbers, and virtual machines with their clusters. Every one of these objects links to the others: a device sits in a rack, a rack sits in a site, a device has interfaces, interfaces hold IP addresses, IP addresses belong to prefixes, and prefixes belong to VRFs or VLANs. It’s not a flat database of independent rows, it’s a graph of your actual network reality.

Why the DCIM + IPAM combination matters

Most teams split these two worlds apart: one tool (or spreadsheet) for “what hardware do we have and where,” and another tool (or spreadsheet) for “which IP is assigned to what.” The problem is that these two worlds are really one world, seen from two angles. An IP address doesn’t exist in a vacuum. It’s assigned to an interface, which belongs to a device, which sits in a rack, which sits in a site. When DCIM and IPAM live in the same data model, you can ask questions like “which prefixes are free in this site” or “which device is using this IP” without mentally joining two systems that have never heard of each other. That’s the whole idea of a source of truth: one place to ask, one correct answer, instead of two places that can quietly disagree.

What you get out of the box

NetBox ships with data models already built for nearly everything that data center and network infrastructure involves:

• Devices, racks, cables - physical inventory, with exact rack positions and cable-to-cable connections documented.
• Power - panels, feeds, outlets, with power allocated per device.
• Sites and locations - a hierarchy of facilities, rooms, and rows of racks.
• Virtual machines and clusters - for virtualization environments, so VMs aren’t ghosts nobody tracked.
• IP addresses and prefixes - hierarchical allocation, with status (active, reserved, deprecated) per address.
• VLANs and VRFs - network segmentation that’s documented, not just configured on a switch and forgotten.
• Circuits and providers - the upstream transport connections and the carriers operating them.
• Autonomous system numbers - relevant if you run your own routing space, as we do.
• REST and GraphQL APIs - anything you can do through the web UI, you can also do programmatically.
• Webhooks - events fired when something changes, useful for driving automated syncs to other systems.
• Custom fields - extend any data model with attributes specific to your organization, without touching code.
• Change logging - a full history of who changed what and when.

Installing NetBox on a VPS

The realistic install path today is the official netbox-community/netbox-docker project, which brings up NetBox alongside PostgreSQL and Redis (Redis handles caching and task queues, it’s not optional):

git clone -b release https://github.com/netbox-community/netbox-docker.git
cd netbox-docker

# create an override file with your settings (ports, superuser, etc.)
cp docker-compose.override.yml.example docker-compose.override.yml

# bring up the stack: netbox, netbox-worker, postgres, redis, redis-cache
docker compose pull
docker compose up -d

# create your first superuser
docker compose exec netbox /opt/netbox/netbox/manage.py createsuperuser

The compose file brings up every container you need (NetBox, its worker for async tasks, PostgreSQL, Redis). If you’re exposing the app port directly on a VPS, use ufw (or the equivalent firewall) to restrict access to where you actually need it, and put a TLS-terminating reverse proxy in front (Nginx or Traefik) instead of leaving the container exposed directly. NetBox holds the complete map of your infrastructure, IP addresses included, so it’s not the kind of service you want sitting on the open internet without authentication and encryption in transit. If you’d rather not manage the VPS, firewall, and OS maintenance yourself, our VPS page has dedicated resources that fit exactly this kind of self-hosted app.

Configuration patterns worth knowing

Model sites, racks, and devices before you throw IPs at the system

The most common mistake is jumping straight to prefixes and IP addresses while skipping the physical hierarchy. NetBox is far more useful when the model is complete: site, then racks, then devices, then interfaces, and only then IP addresses attached to those interfaces. Skip that and you end up with a decent IPAM that has no connection to physical reality, which is half the value you’re leaving on the table.

Keep prefixes and VLANs consistent from day one

Allocate prefixes hierarchically (a parent /24, then child subnets per VLAN or function) and tie every VLAN to its real prefix. Do this consistently and NetBox instantly shows you what space is free, what’s allocated, and where overlaps exist, without you counting rows in a table by hand.

Custom fields for organization-specific metadata

You’ll always have data that doesn’t fit the standard model: who owns a given service, an internal project code, a contract expiry date tied to a specific rack. Custom fields let you extend any model (device, prefix, VLAN, whatever) without bloating the schema with fields nobody else needs. Resist the temptation to dump this into a free-text description field instead, you can’t query that efficiently.

Drive automation from the API, not repeated manual edits

This is the piece that turns NetBox from a nice-looking database into something genuinely useful: when your automation (Ansible, Terraform, whatever you run) reads its dynamic inventory from NetBox and writes IP allocations back through the REST or GraphQL API, the data stays in sync with reality because the automation is what creates that reality. Layer in webhooks if you want other systems to react (notifications, syncs, tickets) the moment something changes in NetBox, instead of waiting for a human to notice.

Where NetBox is not the right answer

NetBox is not a live network monitoring tool. It won’t tell you whether a switch is down right now or whether an interface is dropping packets; you need a separate monitoring and alerting system for that. NetBox describes how your infrastructure should look, not how it’s behaving in real time this second.

It’s also not a configuration management or automation engine by itself. It’s the data, not the execution. You can use it as the source that Ansible, Terraform, or anything else reads from, but it won’t push configuration to your gear on its own.

It’s overkill if you’re running a handful of servers on a single subnet. Its value grows with the number of devices, VLANs, and people involved; below a certain size, a well-maintained spreadsheet can genuinely hold up for a while.

And most importantly: NetBox does not discover your network on its own. It doesn’t scan your infrastructure and populate itself automatically (there are integrations and scripts that can help, but that’s not the default behavior). If you don’t have the discipline to enter data correctly up front and keep it current whenever you make manual changes, you end up with a source of truth that lies, which is worse than having no IPAM at all, because now people trust it wrongly.

Alternatives we considered

• phpIPAM - a lighter IPAM with no DCIM ambitions, a good fit if all you need is IP address management without racks and physical devices.
• Racktables - leans more toward the DCIM side (racks, devices, cabling), with IPAM as a secondary feature. The interface shows its age compared to NetBox, but it works.
• Nautobot - a fork of NetBox, born from the same codebase, with extra emphasis on plugins and integration with network automation platforms. If you’re already deep in the NetBox ecosystem and need more plugin flexibility, it’s worth a direct comparison.

We stayed with NetBox because it covers both DCIM and IPAM in the same data model, with a mature API and a large community behind it, which matters when you’re integrating it with your own automation for the long haul.

So, should you run it?

If you’re managing more than a handful of servers and feel like your infrastructure lives inside one person’s head (often your own), NetBox is worth setting up before it becomes a problem, not after. You can get it running quickly on a VPS with dedicated resources, behind a TLS-terminating reverse proxy. If you’d rather have someone else handle the operating system, firewall, and updates while you focus on modeling your infrastructure, our server administration team can take that part off your plate. And if you’re at the stage of putting your entire network in order, NetBox is where you start writing the truth down instead of just remembering it.

Our answer to that question is Gatus , a health-check and status page dashboard, open source, permissively licensed (MIT-style), written in Go, and shipped as a single lightweight binary or container image you can drop almost anywhere. This isn’t just something we recommend to others: we actually run it in our own datacenter in Bucharest, as an internal tool, to know instantly when something in our own infrastructure, or in a customer-facing service, goes down, before someone outside has to tell us.

What Gatus actually is

Gatus isn’t an agent you install on every machine to report system metrics. It’s not competing with a node exporter or a full-stack monitoring agent. It does one thing, and it does it well: it periodically checks a set of endpoints (HTTP, TCP, ICMP, DNS, TLS) and evaluates the response against conditions you write yourself, in YAML.

A condition looks like this: [STATUS]==200, [RESPONSE_TIME]<300, [CERTIFICATE_EXPIRATION]>168h. Easy to read, easy to write, and flexible enough to cover most real-world scenarios: “respond with 200 in under 300ms”, “the TLS certificate still has at least a week of validity”, “the port is open”, “the DNS record resolves correctly”.

Results are kept in SQLite, so you don’t need an external database just to hold the history, and Gatus also exposes a Prometheus-compatible /metrics endpoint, so you can wire it into an existing monitoring stack if you want to correlate the data with other metrics.

Why this actually matters in production

The real difference between this and “I put a ping in cron” comes down to two things: configurable failure/success thresholds, and built-in alerting integrations. You don’t want an alert on the first timeout (networks have blips), but you also don’t want to find out about a real outage 20 minutes later. Gatus lets you define exactly how many consecutive failures mean “this is actually down” and how many consecutive successes mean “this has actually recovered”, per endpoint. And once that threshold is hit, the alert goes out over email, Slack, Telegram, PagerDuty, or other supported channels, without you having to write your own debounce logic.

What you get out of the box

• A ready-to-use web status page showing the current state and recent history of every monitored endpoint.
• Multi-protocol checks: HTTP/HTTPS, TCP, ICMP (ping), DNS, and TLS/certificate validation, all from the same configuration format.
• Scriptable conditions on status code, response time, body content, certificate expiration, and other fields exposed by the response.
• Configurable failure-threshold and success-threshold, so you control alerting noise instead of it controlling you.
• Ready-made notification integrations for the most common channels (email, Slack, Telegram, PagerDuty, and others).
• A Prometheus-format /metrics endpoint, for anyone who wants to feed the data into an existing stack.
• Zero external database: history lives in SQLite, right next to the binary.
• Fully declarative configuration: everything you monitor is defined in YAML files, which means you can put the config in Git, review a pull request that adds a new endpoint, and have a complete change history for your monitoring, exactly like any other piece of infrastructure-as-code.

Installing Gatus on a VPS

The simplest way to try Gatus is with Docker, directly on a VPS. All you need is a configuration file mounted as a volume and one exposed port.

mkdir -p ~/gatus/config
cat > ~/gatus/config/config.yaml <<'EOF'
endpoints:
  - name: website
    url: "https://example.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 500"
      - "[CERTIFICATE_EXPIRATION] > 168h"

  - name: api-backend
    url: "tcp://example.com:5432"
    interval: 60s
    conditions:
      - "[CONNECTED] == true"
EOF

docker run -d \
  --name gatus \
  --restart unless-stopped \
  -p 8080:8080 \
  -v ~/gatus/config:/config \
  twinproduction/gatus

Or, if you prefer docker-compose, the equivalent is:

services:
  gatus:
    image: twinproduction/gatus
    container_name: gatus
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./config:/config

One thing worth keeping in mind from the start: if the VPS has ufw enabled (as any internet-facing server should), port 8080 isn’t opened automatically just because the container is running. Either explicitly open the port with ufw allow 8080/tcp (and restrict it to your own IPs if you can), or, better yet, put Gatus behind a reverse proxy with TLS and leave only 80/443 open, keeping 8080 reachable only from the server’s internal network. For a status page you and your team check, the second option is almost always the right call.

If you don’t already have a box to run this on, spin one up quickly on a VPS with enough resources for a small container, Gatus has no serious hardware requirements.

Configuration patterns worth knowing

Reasonable failure and success thresholds

Don’t set failure-threshold: 1 unless you genuinely want an alert on the first network blip. In practice, a threshold of 2-3 consecutive failures, at a 30-60 second check interval, gives you an honest signal without waking you up for every transient glitch. Symmetrically, a success-threshold of 2 confirms the recovery is real, not just one lucky response sandwiched between two outages.

Certificates that expire quietly

The condition [CERTIFICATE_EXPIRATION] > 168h (one week) on every HTTPS endpoint you monitor is probably the cheapest insurance you can configure. An expired certificate discovered by a customer before you is an unpleasant conversation that a single line of YAML avoids entirely.

Checks beyond HTTP

Not everything that matters answers on port 80/443. A database on TCP, a DNS record that needs to resolve to the right IP, an ICMP ping to a network device, a TLS certificate on a non-web port, all of these fit into the same list of endpoints, with the same kind of conditions. In practice, a single tool covers both your web application and the infrastructure behind it.

Alert by group, not per individual endpoint

Once you have dozens of endpoints, per-service alerting can become noise in its own right. Group endpoints logically (public-facing, internal, database, network) and think about the right notification channel for each group: a Slack channel for “worth watching” alerts, PagerDuty or direct email for the ones that genuinely need immediate action.

Where Gatus is not the right answer

Gatus is excellent at one thing: “is this endpoint available and responding the way I expect?”. Don’t try to use it as a substitute for a full observability stack. It doesn’t do distributed tracing, it won’t tell you why latency spiked on a specific database query, it doesn’t profile your application, and it doesn’t replace a centralized logging system. If you need to understand an application’s internal behavior, not just whether it responds from the outside, you need application metrics, structured logs, and probably tracing, alongside Gatus, not instead of it.

Also, if your team already has a mature Prometheus/Grafana stack with blackbox checks configured, you might not gain much by bolting on Gatus separately, beyond a dedicated status page that’s easier to show to people who don’t read PromQL dashboards.

Alternatives we considered

• Uptime Kuma : probably the best-known alternative, with a web interface much more oriented toward click-and-configure. If you’d rather add monitors from a UI than from version-controlled YAML files, Uptime Kuma is a solid choice. The trade-off is that configuration history lives in the application’s own database, not in Git, which makes code review and change tracking harder.
• Prometheus Blackbox Exporter : if you already run Prometheus and just want probe-style checks (HTTP, TCP, ICMP, DNS) integrated directly into that ecosystem, without a separate status page, blackbox exporter does exactly that, but it stays one more piece inside a Prometheus stack rather than a standalone product with its own UI.
• Healthchecks.io : a different angle, focused on monitoring cron jobs and scheduled tasks (a “dead man’s switch”: if the job doesn’t check in on time, you get alerted), rather than active endpoint checks. It can be self-hosted, and pairs well with Gatus as a complement, not necessarily a replacement.

The reason we picked Gatus was simple: config-as-YAML-in-Git matches exactly how we treat the rest of our infrastructure, as infrastructure-as-code, reviewed in pull requests, not quietly edited from a UI that doesn’t remember who changed what.

So, should you run it?

If you’re a small team or a solo developer who wants to be the first to know, not the last, when something breaks, Gatus is a solid choice: easy to install, easy to understand, and its configuration lives next to the rest of your code, not in a separate database. It’s not a substitute for full observability, but for the basic question, “is this service actually up right now”, it gets the job done without unnecessary complexity.

If you need a place to run it without the hassle, a VPS is more than enough for a dashboard like this, and if you’d rather not deal with the server administration side yourself, firewall setup, updates, hardening, our server administration team can take over the operational part while you focus on what the dashboard shows.

CloudPanel , the open-source panel from MGT-COMMERCE, has been settling into that gap for the last couple of years. The community edition is the only edition, which is a refreshing change from the freemium pattern. As of v2.5.3 (December 2025) it sits at roughly 1.8k stars on GitHub and ships cloud images for every major hyperscaler. We have been running it on a VPS in our Bucharest datacenter for several weeks. This is the field report.

What CloudPanel actually is

Architecturally, CloudPanel is a thin management layer over a hardened Nginx, PHP-FPM, MySQL or MariaDB stack. It is not its own web server, not its own database, not a Docker swarm or a Kubernetes wrapper. The panel writes Nginx vhosts, manages PHP-FPM pools per site, provisions Linux users so each site is isolated at the OS level, and exposes a UI to do all of that without you remembering the exact php-fpm config knob you wanted last Tuesday.

If that sounds dull, that is the point. The interesting design decision in CloudPanel is what it does not try to be: it is not a hosting reseller platform, not a billing system, not a mail server, not a DNS authoritative server. Those omissions are deliberate, and they are also the first thing to understand before you adopt it.

The stack you get

• Web tier: Nginx, configured as the front for every site. There is no Apache option.
• PHP: multiple versions installed in parallel (7.x and 8.x), switchable per site with a click. Running an old PrestaShop on 7.4 next to a Laravel 11 app on 8.3 on the same box is a non-event.
• Databases: MySQL 8.4, 8.0, 5.7 or MariaDB 11.8, 11.4, 10.11, 10.6. You pick one at install time via a DB_ENGINE variable, the rest are not installed.
• Application types: PHP, Node.js, Python, static sites, and reverse-proxy passthroughs (handy for putting a panel-managed Nginx in front of an app you run elsewhere).
• TLS: Let’s Encrypt baked in, with HTTP-01 validation and auto-renewal.

The control plane itself is a Symfony PHP app behind its own Nginx vhost on port 8443. That single port is the entire management surface; close it to the world and the only people who can touch the panel are people on your management network.

What you get out of the box

The community edition (which, again, is the only edition) ships with:

• Site isolation at the OS level. Each site gets its own Linux user, its own PHP-FPM pool, its own home directory. A compromised WordPress on site A does not have read access to site B’s files. This is the single feature that matters most for shared environments.
• Free Let’s Encrypt SSL, one click per site, auto-renewed by cron.
• UFW firewall management with a sane default policy and a UI to add rules.
• Two-factor authentication for the panel admin, TOTP based.
• IP and Bot blocker, which lets you blacklist user agents and IP ranges without dropping into Nginx config.
• Cloudflare integration, primarily for trusting the right X-Forwarded-For chain so your access logs are not full of Cloudflare edge IPs.
• Vhost templates per app type, pre-configured for WordPress, Magento, Symfony, Node, generic PHP, and so on. The templates are sensible (gzip, brotli, security headers) and editable.
• Per-site cron, FTP, file manager, and database management UI.
• Backup destinations to S3-compatible buckets, including MinIO and Backblaze B2, configurable per site.

What it does not ship: a mail server, a DNS authoritative server, a billing/customer portal, a one-click app installer like Softaculous, or any kind of multi-server clustering. If your mental model of a control panel is “cPanel feature parity”, CloudPanel will feel sparse. If your mental model is “the smallest thing that lets me stop hand-editing Nginx vhosts”, it will feel right-sized.

Installing CloudPanel on a VPS

The install path is genuinely a one-liner and the docs do not pretend otherwise. Minimum sane resources are 1 vCPU, 2 GB RAM, 10 GB disk. Supported OSes are Debian 11, 12, 13 and Ubuntu 22.04, 24.04 LTS, on x86_64 or arm64. Anything older than Debian 11 is not supported and you should not try.

On a fresh server, log in as root and update the base packages first:

apt update && apt -y upgrade && apt -y install curl wget sudo

Then run the installer. The exact command from the official docs (with sha256 verification, which you should not skip):

curl -sS https://installer.cloudpanel.io/ce/v2/install.sh -o install.sh; \
echo "6eac061df80f08b75224fcd7fce2f115e201696d8a6122e31abf7259a813b462 install.sh" | \
sha256sum -c && sudo DB_ENGINE=MYSQL_8.4 bash install.sh

Pick the DB_ENGINE value that matches your needs. Common choices are MYSQL_8.4, MYSQL_8.0, MARIADB_11.8, MARIADB_10.11. If you want MariaDB because your app stack assumes it, decide now, the database engine is not swappable post-install without manual surgery.

The script will install Nginx, PHP, the chosen database, the panel itself, and the supporting cron jobs. It takes 3 to 6 minutes on a 1 vCPU VPS, longer on slow disks.

Once it finishes, the management UI is at https://<your-server-ip>:8443/. The first request lands on a setup wizard where you create the admin user, and that is the moment of risk: between the install finishing and you completing the wizard, anyone who can reach port 8443 can claim the admin account. The official guidance is to access the panel “as fast as possible”. The better guidance is to firewall port 8443 down to your own IP before you even start the install:

ufw allow from YOUR_OFFICE_IP to any port 8443
ufw deny 8443

If you are running this on a DreamServer VPS , put the same rule in your provider-side network firewall too. Host-level rules are fine, network-level rules are better, both is correct.

After the wizard, turn on TOTP two-factor for the admin account from Account > Security. There is no excuse not to.

Adding a real PHP site with SSL

The mental model is: every site is an isolated user with a dedicated docroot under /home/<sitename>/htdocs/<domain>/. You do not edit Nginx vhosts by hand, the panel does that for you when you create or modify a site.

In the UI, Sites > Add site:

• Site type: pick the closest match (WordPress, Magento, Symfony, generic PHP, Node.js, static, reverse proxy). The template prefills sensible defaults for that app type.
• Domain: example.com plus any aliases. Wildcard subdomains are supported via DNS-01 if you wire it up to Cloudflare or Route53; otherwise stick to explicit names.
• PHP version: 7.4 through 8.3 in the dropdown. Switchable later.
• Site user: the Linux user that will own this site. Defaults to a sane derivation of the domain.

Save, point your A/AAAA records at the panel host, then come back and click SSL/TLS > Let’s Encrypt. The panel does the HTTP-01 dance, drops the cert into /etc/nginx/ssl/, and reloads. Sixty seconds, no manual certbot.

To verify the site is actually live:

curl -I https://example.com

You should see a 200 (or your app’s redirect) and a server: nginx header. If you see Apache or anything other than Nginx, something is wrong with your DNS, not with CloudPanel.

Configuration patterns worth knowing

A few patterns we have found useful beyond the defaults.

Use the per-site PHP settings, not php.ini

CloudPanel exposes memory_limit, max_execution_time, upload_max_filesize, and friends per site in the UI. Use those. Editing the global /etc/php/8.3/fpm/php.ini works exactly once, until your next package update wipes it.

Vhost custom snippets, not direct edits

Every site has a Vhost > Custom snippets field where you can paste extra Nginx directives. Use that for cache rules, redirects, security headers. Do not edit the panel-generated vhost file directly; the next save through the UI will overwrite your edits.

Cron over web cron

For WordPress in particular, disable WP-Cron in wp-config.php (define('DISABLE_WP_CRON', true);) and add a real cron entry in the panel’s Cron Jobs tab. WP-Cron firing on every page load is one of the more common reasons a small WordPress site feels slow under modest load.

Backups: panel + filesystem, both

CloudPanel’s S3 backups are good for application files and databases. They are not a substitute for a full-VM backup. We pair the panel’s backups with Proxmox Backup Server snapshots at the hypervisor level, so a “rebuild this VPS from scratch” recovery is a single restore instead of a panel-reinstall plus a per-site restore.

Trust the bot blocker more than your gut

The IP and Bot blocker has a curated list of known scrapers and credential stuffers. Turn it on for any public site and check the access logs a week later. The number of requests it silently drops, mostly stale WordPress brute-force toolkits, is consistently higher than people expect.

CloudPanel vs the alternatives

For completeness:

• cPanel/WHM: the industry default, mature, expensive, RHEL-centric. If you bill clients per cPanel account and need feature parity with the rest of the cPanel ecosystem (CageFS, JetBackup, WHMCS integration), it is still the right answer. CloudPanel is not trying to compete here.
• Plesk: similar pricing tier to cPanel, friendlier UI, runs on more OSes. If you are already paying for Plesk and it works, there is no reason to switch.
• aaPanel: free, broad feature set, Chinese-origin with an opaque telemetry story that has made some operators nervous. The UI is dense in a way that CloudPanel deliberately is not.
• HestiaCP: free, fork of VestaCP, ships with mail and DNS, more “do everything” in scope. Older codebase, more rough edges, but the right pick if you specifically need bundled mail and DNS.
• CyberPanel: free community edition, OpenLiteSpeed-centric, optimized for LiteSpeed cache. Good if you have already committed to the LiteSpeed ecosystem; otherwise Nginx is more portable.

CloudPanel ended up being the cleanest fit for “I want a modern panel that manages Nginx, PHP and databases for a small number of sites, without giving me features I will not use”. Your weights might be different.

Where CloudPanel is not the right answer

Worth being honest about the limits.

• No mail server. If you need IMAP/SMTP hosting on the same panel, CloudPanel will not give it to you. You will run a separate mail box (or, more sensibly, route mail through a managed provider).
• No authoritative DNS. The panel does not run BIND/PowerDNS for you. You manage DNS at your registrar, at Cloudflare, or on a separate authoritative service. For our customers this is usually fine because we provide DNS at the LIR/network layer anyway.
• No multi-server. One panel manages one server. There is no concept of a cluster, no shared filesystem story, no failover. If you have more than a handful of servers, you are looking at orchestration tooling, not a panel.
• No customer billing. This is not a hosting-reseller platform. If you need to sell hosting plans with invoicing, you bolt the panel onto a separate billing system.
• Self-hosting is still self-hosting. You patch the OS, you watch the disk fill up, you deal with the occasional MySQL surprise. If your team does not want that, a managed service is cheaper in operator hours than free software is in your time.

So, should you run it?

If you self-host a handful of PHP, Node or Python sites on a VPS or dedicated server, and you have been hand-editing Nginx vhosts long enough to be bored of it, CloudPanel is worth a Sunday afternoon. The install is a single command, the UI gets out of your way, and the per-site Linux user model means a compromised plugin on one site is not a panel-wide incident.

If you are running it in production, put it on a server with a real backup story (Proxmox Backup, snapshots, your call), firewall the management port, and treat the panel as critical infrastructure. The Nginx and PHP configs the panel writes are easy to rebuild; the database of site definitions and users is what you would actually miss.

We run CloudPanel ourselves in front of a few internal sites and recommend it to customers who ask for “something between bare Nginx and cPanel”. If you want to try it on infrastructure you do not have to build first, our VPS plans start small enough to make the experiment cheap, and our server administration service covers the install and tuning if you would rather skip the learning curve. If something does not fit, get in touch and we will tell you honestly whether it is the right tool for the job.

The code is on GitHub , the install is one command, and you will know within an hour whether it earns a spot in your stack.

SafeLine , the open-source WAF maintained by Chaitin Tech , has been quietly building momentum around that exact gap. As of v9.3.4 (released 17 April 2026) it sits at 21k+ stars on GitHub, runs on more than 180,000 installations and is licensed under GPL-3.0. We have been testing it on a VPS in our Bucharest datacenter for a few weeks. This post is the field report.

What SafeLine actually is

Architecturally, SafeLine is a reverse proxy with a detection engine in front of your origin. Traffic hits SafeLine on ports 80/443, gets inspected, and either passes through to your upstream application or is challenged, throttled, or blocked. The reverse proxy is built on a hardened Tengine fork (Tengine being Alibaba’s nginx derivative), with detection logic implemented as native modules in C++ and Lua. The management plane is a Go service backed by PostgreSQL.

If that sounds a lot like nginx + ModSecurity, the comparison is fair on paper and unfair in practice. The interesting part is what happens between request arrival and the upstream call.

Why the detection engine is different

Most open-source WAFs you have probably touched, ModSecurity with the OWASP Core Rule Set being the canonical example, are fundamentally regex engines. They match patterns in the request and decide. The trade-off is well known: tighten the rules and you start blocking legitimate users, loosen them and attacks slip through. Anyone who has ever paranoia-mode’d ModSecurity in front of a WordPress site knows the false-positive tax.

SafeLine takes a different route. It parses the request as a syntactic structure (SQL grammar for query parameters that look database-shaped, JS AST for script content, shell parser for command patterns) and then evaluates whether the parsed result has the semantic shape of an attack. A query with quotes is not automatically suspicious; a query whose parsed form would change SQL execution flow is. The Chaitin team publishes benchmark numbers around 99.4% true-positive accuracy in their balance mode, which is in the range of commercial offerings.

You should still verify on your own traffic, all WAF benchmarks have a strong “tested on the dataset we built” flavour, but in practice the false-positive rate on our test workloads has been substantially lower than ModSecurity with CRS at paranoia level 2. That alone changes the operational story: a WAF you do not have to constantly whitelist around is a WAF that stays on.

What you get out of the box

The community edition (which is what we are talking about, the Pro edition is announced but not generally available at the time of writing) ships with:

• Web attack detection for the OWASP-canonical categories: SQL injection, XSS, command and code injection, XXE, SSRF, path traversal, deserialization patterns.
• Rate limiting per IP, per path, per session, with configurable windows and burst behaviour.
• Anti-bot challenge, a JavaScript proof-of-work that legitimate browsers solve transparently and headless scrapers stumble on.
• Authentication challenge, a separate gate you can put in front of admin panels (think: a captcha-like step before reaching /wp-admin/).
• Dynamic HTML/JS encryption, which mangles client-side identifiers per request so scrapers and credential-stuffing tools cannot easily target form fields.
• Geo blocking by country, useful for sites with no business outside a specific region.
• Logging and analytics dashboard, which is genuinely useful (more on this below).

What it does not do: it is not a CDN. It does not cache static assets, does not give you POPs around the world, does not protect against L3/L4 volumetric DDoS at the network edge. SafeLine is a layer-7 application firewall. If you are taking 100 Gbit of UDP reflection, you need network-layer mitigation upstream, the kind we run at AS57050 with our own RTBH and sFlow setup , before the traffic ever reaches your VPS.

Installing SafeLine on a VPS

This is the part where most “open source WAF” projects make you regret the decision. SafeLine genuinely does not. The official one-liner does the right thing on a clean Debian or Ubuntu box.

Minimum sane resources: 2 vCPU, 4 GB RAM, 10 GB free disk. The script will warn under 5 GB free. SSSE3 CPU instructions are required (any x86 CPU made in the last 15 years has them, but if you are running on something exotic, check /proc/cpuinfo). Both x86_64 and arm64 are supported.

On a fresh server:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)"

The script will:

1. Install Docker and the Compose plugin if they are missing.
2. Drop a docker-compose stack at /data/safeline/.
3. Pick an unused private subnet (it tries 172.22.222.0/24, 169.254.222.0/24, 192.168.222.0/24 in order).
4. Generate a random 32-char Postgres password.
5. Pull and start four containers: safeline-pg, safeline-mgt, safeline-detector, safeline-tengine.

Once it finishes, the management UI is at https://<your-server-ip>:9443/ with a self-signed certificate. To grab the initial admin credentials:

docker exec safeline-mgt resetadmin

That command prints a one-time username and password you can use for the first login. Change the password immediately after you are in. While you are at it, restrict port 9443 with a firewall rule, the management plane should not be exposed to the internet:

ufw allow from YOUR_OFFICE_IP to any port 9443
ufw deny 9443

If you are running this on a DreamServer VPS , the same rule belongs in your provider’s network firewall too, do not rely on host-level rules alone for management interfaces.

Putting a real site behind it

Adding a protected site is straightforward but the mental model takes a minute to click. SafeLine becomes the public-facing endpoint; your real application becomes an internal upstream that only SafeLine talks to.

In the management UI, Sites > Add site:

• Domain: example.com (and any aliases you serve).
• Port: 80 for plain HTTP, 443 for HTTPS, both if you want SafeLine to do the redirect.
• Upstream: the IP and port of your origin, for example 10.0.0.5:8080. If your origin lives on the same box, use the docker bridge gateway (typically 172.17.0.1 or whatever the script picked) and the port your application listens on.
• TLS certificate: paste a cert and key, or upload a Let’s Encrypt-issued one. SafeLine does not currently auto-issue certificates, you bring your own.

Save, then point your domain’s A/AAAA records at the SafeLine host. Within a few seconds the site shows up under Detection logs and you can watch live traffic flow through.

The first thing to verify is that SafeLine is genuinely inline. Send a deliberately bad request:

curl -k "https://example.com/?id=1' OR '1'='1"

You should get a SafeLine block page (HTML body, HTTP 403 by default) and a corresponding entry in the detection log. If the request goes through to your application, your DNS or upstream config is wrong, fix that before you trust anything else.

Configuration patterns worth knowing

A few patterns we have found genuinely useful beyond the defaults.

Whitelisting health checks

If your monitoring system pings /health from a known IP, do not let SafeLine score those requests. Add an Allow rule at the top of the policy chain matching source IP and path, with action “skip detection”. The point is not to save CPU, it is to keep your detection logs uncluttered with traffic you trust.

Rate limit before block

When you turn on rate limiting for a login endpoint, prefer challenge over block for the first threshold. A bot that runs into a challenge silently dies; a human who fat-fingered their password three times in a row gets through. Reserve the block action for the second threshold (say, 30 requests per 5 minutes from a single IP).

Anti-bot for the entire site, not just login

Counter-intuitive but useful: turn on the JS challenge sitewide for low-value paths (the homepage, the blog) on a small percentage of traffic. The bots that fail the challenge there are the same ones that would later try your login form. You learn a lot about what is hitting you before any sensitive endpoint sees the traffic.

Authentication challenge for admin paths

For anything matching /admin*, /wp-admin*, /phpmyadmin*, add an authentication challenge layer. SafeLine implements this as an extra gate that requires solving a CAPTCHA-style challenge before the request reaches your application. It does not replace your application’s auth, it just stops automated tools from ever knocking on the door.

Read the logs

The dashboard at Statistics > Detection logs shows every blocked request with the parsed reason: which engine triggered (semantic SQLi, regex XSS, anti-bot), the request body, the score. Spend an hour going through it the day after you turn SafeLine on. You will find that most of your “weird traffic” looks the same: a handful of mass-scanning toolkits hitting the same WordPress admin paths and the same exposed .env URLs.

Where SafeLine is not the right answer

It is worth being honest about the limits.

• Not a CDN. No caching, no edge POPs. If your performance story depends on edge proximity, you still need a CDN in front of (or beside) SafeLine.
• Not for sub-millisecond paths. Every request goes through detection. Median overhead in our tests was 1 to 3 ms on warm caches, which is fine for almost any web app, but if you are running an HFT API, this is not your tool.
• Pro features are not all open. Some of the more sophisticated dynamic-protection features and the multi-node clustering are clearly aimed at the upcoming Pro edition. The community edition is generous, but if you are protecting a fleet of dozens of sites with HA requirements, plan for that.
• Self-hosting is not free. You are running another stateful service that needs backups, OS patching, and the occasional Postgres babysitting. If your team does not want that, a managed WAF will be cheaper in operator hours.

Alternatives we considered

For completeness: we also looked at BunkerWeb (nginx-based, very approachable, weaker semantic detection), Coraza (a Go-native ModSecurity reimplementation, great if you want to embed WAF logic directly in a service mesh), and the OWASP CRS on a stock nginx with ngx_security_module (battle-tested, infinitely tunable, false positives are your hobby now).

SafeLine ended up being the cleanest fit for “I want a real WAF in front of a small fleet of self-hosted sites without becoming a WAF specialist”. Your weights might be different.

So, should you run it?

If you self-host PHP, Node, Python or Go web applications on a VPS or dedicated server and you have been meaning to “do something about security headers and bot traffic”, SafeLine is worth a Sunday afternoon. The install is genuinely fast, the detection works without you fighting it, and the dashboard tells you something true about your traffic.

If you are running it in production, put it on a server with a real backup story (Proxmox Backup, snapshots, your call) and treat the management plane as critical infrastructure. The detection containers can be rebuilt in a minute; the configuration in Postgres is what you would actually miss.

We run SafeLine ourselves in front of a couple of internal services and recommend it to customers who ask. If you want to try it on infrastructure you do not have to build first, our VPS plans start at small enough sizes to make the experiment cheap, and our server administration service covers the install and tuning if you would rather skip the learning curve.

Either way, kicking the tires on SafeLine is a better way to spend an evening than reading another “top 10 WAF” listicle. The code is on GitHub, the install is one command, and you will know within an hour whether it earns a spot in your stack.

The project lives at github.com/louislam/uptime-kuma , under the MIT license, created and maintained by Louis Lam. We run Gatus for our own status monitoring, because we prefer config-as-code, but Uptime Kuma is a very good alternative if you want an experience driven entirely from the web UI, without writing a single line of YAML.

What Uptime Kuma actually is

Uptime Kuma is essentially the self-hosted version of services like UptimeRobot or Pingdom: you add a monitor, choose what to check and how often, and the app shows you response time, uptime percentage, and sends you notifications when the state changes.

Technically, it’s a Node.js app, runs in a single container, and stores everything in SQLite, no separate database needed. The frontend is built in Vue and talks live to the backend via socket.io, so the dashboard updates in real time without a page refresh, which gives it the feel of a modern app rather than an old-school sysadmin tool.

The monitor types covered out of the box are surprisingly broad: HTTP(S) with status code or keyword checks on the response, TCP port, ping, DNS records, Docker containers (checked directly through the socket), gRPC, and push-type monitors, where an external job (a cron, a backup script) sends a “heartbeat” to Uptime Kuma instead of being polled by it.

Why this matters

For a solo developer or a small team, a monitoring stack you never fully configure helps nobody. Uptime Kuma gives you useful observability in five minutes: install it, add a few URLs, set up a Telegram notification, done. You don’t need templates, discovery, or complex triggers, just the answer to “is it up or not”.

What you get out of the box

• A reactive dashboard, with live websocket updates, no manual page refresh needed.
• Status pages, public or private, customizable, with support for multiple pages for different audiences (one public page for customers, one internal for the team).
• Over 90 notification integrations: Telegram, Slack, Discord, email, generic webhook, PagerDuty and many more.
• Multi-user support and 2FA for access to the instance.
• TLS certificate expiry monitoring, with alerts a few days before expiration.
• Maintenance windows, so you don’t get false alerts during planned maintenance.
• Simple configuration import/export and a basic API for custom integrations.

Installing Uptime Kuma on a VPS

A single container, with a volume for persistent data:

docker volume create uptime_kuma_data

docker run -d --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime_kuma_data:/app/data \
  louislam/uptime-kuma:1

On first access at http://<vps-ip>:3001, you’re asked to create the admin account. In production, put it behind a reverse proxy with TLS, Uptime Kuma doesn’t have its own certificate, and there’s no reason to expose port 3001 directly to the internet.

With ufw:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw deny 3001/tcp
ufw enable

Resource needs are minimal: the container runs comfortably on the smallest VPS we offer, even with a few dozen active monitors checking at one-minute intervals.

Configuration patterns worth knowing

Push monitors for internal jobs

Instead of waiting for Uptime Kuma to periodically check whether a cron job or backup script ran, you can set up a “push” monitor: the script itself sends an HTTP request to Uptime Kuma at the end of its run. If the request doesn’t arrive within the expected interval, the monitor flips to “down”. It’s the “dead man’s switch” technique, useful for jobs that run infrequently (daily backup, weekly sync) where classic polling doesn’t make sense.

Separate status pages per audience

You can create a simple public status page with only the services relevant to customers, and a separate, internal page with all the technical detail for the operations team. Both live on the same instance, but show different lists of monitors.

Retries and flapping resistance thresholds

Each monitor has a configurable number of consecutive failed checks before it triggers an alert (“retries”), plus a resend interval if the problem persists. Set correctly, it eliminates false alerts for a two-second network blip while still notifying you quickly about a real problem.

Docker monitor type for small self-hosted stacks

If you run a few containers on the same VPS, the Docker monitor type checks the container’s state directly through the Docker socket, without making an HTTP request to it, useful for internal services with no exposed port.

Where Uptime Kuma is not the right answer

All configuration lives in SQLite, managed through the web UI. If you want monitoring to be version-controlled in Git, reviewed through pull requests, and deployed identically across multiple environments, a config-as-code tool like Gatus fits better, we detailed that approach in our monitoring stack article .

It’s not a metrics platform: it gives you binary status (up/down) and latency, not detailed graphs of CPU, memory, or custom application metrics. For that you need VictoriaMetrics/Prometheus and Grafana.

Finally, it’s a single-node instance with no built-in replication. If your public status page runs on the same server that hosts the monitored services, an incident that takes down the server also takes down your monitor, exactly when you need to know what’s happening. For critical status pages, run the instance on infrastructure separate from what it monitors.

Alternatives we considered

Gatus is our preferred alternative for config-as-code monitoring: everything is defined in YAML, version-controlled in Git, with no hidden state in a database, a good fit for teams who want the entire monitoring configuration in one place, reviewable as code.

Checkmk or Zabbix are much heavier than you need for uptime monitoring alone, but worth considering if you end up also needing deeper infrastructure monitoring (CPU, memory, system services), not just external availability.

Statping-ng or Cachet are other, older status page options, but with notification and maintenance ecosystems less active than Uptime Kuma’s.

So, should you run it?

If you need a quick answer to “is my site up?” plus a presentable status page for customers, and you want everything ready to go in five minutes without writing any configuration, Uptime Kuma is the obvious choice. When you grow past a few dozen monitors or want Git-versioned configuration, consider Gatus or a heavier infrastructure tool.

You can spin up the container above on a VPS with us in a few minutes, or let our server administration team set up your monitoring and notifications from scratch.

SmokePing (oss.oetiker.ch/smokeping ) is the tool built exactly for that gap, written by Tobi Oetiker, the same author behind RRDtool and MRTG - two tools half the network monitoring world uses without necessarily knowing who wrote them. GPL licensed, it’s a classic Perl tool that never tried to be anything other than very good at one job: measuring latency repeatedly, over time, and displaying it in a way that makes problems obvious at a glance.

What SmokePing actually is

SmokePing periodically sends probes (FPing by default, but it also supports DNS, HTTP(S), SSH, TCP and many other protocols through its pluggable probe system) toward a list of targets and measures the response time for each attempt. Rather than keeping only an average, it retains the full distribution of measurements within an interval, and the result is stored in RRDtool, the same round-robin database also used by MRTG.

The project’s visual signature - where the name comes from - is the “smoke” graph: for each time bucket, instead of a single average-latency line, you see a grey band, thicker or more diffuse depending on how spread out the individual measurements were. A thin, constant band means stable latency. A thick, “smoky” band means high jitter - large variance between packets, exactly what a user experiences as “inconsistent lag.” Packet loss overlays on the same graph via color (from green to red), so you can see three things at once, at a glance: average latency, its variance, and the percentage of lost packets.

For larger networks, SmokePing supports a master/slave setup: a central server coordinates multiple geographically distributed measurement nodes, each reporting back to the master. Useful when you need to know not just “how far is X from me,” but “how far is X from several different points in the network.”

Why this matters

The difference from classic up/down monitoring is that SmokePing answers a different question. An uptime check tells you “the server responded at time X.” SmokePing tells you “how did the network path to the server behave over the last hour, week, month” - and that second question is the one that matters when you’re trying to figure out why a customer complains about a bad experience even though all your classic alerts are silent. Many real network problems (an intermittently saturated link, a switch starting to drop packets before it fully dies, an unstable peering session) show up in jitter and partial loss well before they become a full outage.

What you get out of the box

• A latency graph with a “smoke” band showing the full distribution of measurements, not just the average
• Visual overlay of packet loss via color coding, on the same graph
• Pluggable probes: FPing (default), DNS, HTTP(S), SSH, TCP, and many more through Perl modules
• RRDtool storage, so compact historical graphs with decreasing resolution as data ages
• Master/slave configuration for distributed measurements from multiple vantage points
• Configurable alerting on latency or packet-loss thresholds
• A web interface for interactive navigation through graphs and zooming into time ranges

Installing SmokePing on a VPS

SmokePing is a lightweight tool, well suited to a small dedicated monitoring VPS - in fact, a vantage point separate from the infrastructure you’re monitoring is ideal, so you see latency the way the outside world sees it, not only from inside your own network.

# on Debian/Ubuntu
apt update
apt install smokeping fping apache2

# enable the CGI module and the Apache config shipped with the package
a2enmod cgi
a2enconf smokeping-apache2
systemctl reload apache2

# targets to monitor are defined in /etc/smokeping/config.d/Targets
# minimal example to add under an existing section:
#   + MyServer
#   menu = My Server
#   title = Latency to production server
#   host = 203.0.113.10

systemctl restart smokeping

After install, the web interface is available by default at /smokeping under Apache, and the daemon starts accumulating data immediately - the first useful graphs appear after a few hours, but real trends (recurring jitter at certain hours, packet loss in a pattern) only become visible after a few days of collection.

# web interface (Apache), ideally restricted to your IP or a private network
ufw allow from <your_IP> to any port 443 proto tcp
# FPing needs the CAP_NET_RAW capability for ICMP, handled automatically
# by the Debian package - no extra open port required beyond this

If you’re using a master/slave setup, slave nodes need connectivity to the master on whatever port you configure for the RPC channel between them (typically an SSH tunnel or a dedicated channel, depending on how you set it up).

Configuration patterns worth knowing

Pick the right probe for what you actually want to measure

FPing measures network-level latency (ICMP), but if you want to know how long a service actually takes to respond (not just whether the host is “up”), use protocol-specific probes: DNS for a resolver, HTTP(S) for a site, SSH for a server you connect to frequently. A server can answer ICMP perfectly while the web service running on it has high latency for entirely different reasons.

RRDtool resolution decreases over time, by design

RRDtool keeps high-resolution data for recent periods and progressively aggregates older periods, so files don’t grow forever. That means if you want to investigate a specific event from three months ago at second-level granularity, you likely won’t have it - plan your alerting thresholds and archiving around that, don’t assume you have full history at maximum resolution indefinitely.

Use master/slave to tell “my problem” from “their problem”

With a single measurement point, you can’t know whether a latency spike is caused by your local network, an intermediate ISP, or the destination itself. With slave nodes in different locations (a different datacenter, a different ISP), you can correlate: if all nodes see the same problem at the same time, the cause is likely at the destination or a shared transit point; if only one node sees it, the problem is local to that vantage point.

Alerts deserve thought-out thresholds, not defaults

SmokePing can send alerts on latency and packet-loss thresholds, but the defaults know nothing about your specific network. 150ms latency can be entirely normal for an intercontinental link and alarming for a local one. Set thresholds per target, not globally.

Where SmokePing is not the right answer

SmokePing measures network-level latency and loss, but it doesn’t replace a full application or infrastructure monitoring system (CPU, memory, disk, processes). For that you need a separate stack (Prometheus/Grafana, Zabbix, Checkmk, or others), which SmokePing can complement, not replace.

Its interface is also functionally vintage: static, server-side-rendered RRDtool graphs, no modern interactive drag-and-drop dashboards. If you want cross-metric correlation in a single panel (latency + CPU + traffic on the same graph), you’ll need to export the data or pair it with another tool.

Finally, for very large networks with hundreds of targets, configuration through text files and a hierarchical menu structure can become unwieldy compared to modern solutions with automatic discovery.

Alternatives we considered

• Prometheus Blackbox Exporter + Grafana : a modern stack with flexible time-series storage and interactive dashboards, but it takes more pieces wired together to reach the same visual result
• MTR : combines traceroute with repeated per-hop latency measurements, excellent for point-in-time diagnosis, but not for continuous long-term monitoring
• Zabbix : a full monitoring platform that also includes ICMP latency measurements, with more sophisticated alerting, but a steeper learning curve and a much larger configuration surface

So, should you run it?

If you’ve ever needed to answer “was the connection really unstable yesterday between 2 and 4pm, or is the customer imagining it,” SmokePing is exactly the tool that gives you the answer, with visual proof at hand. It’s easy to install, light on resources, and its smoke graph remains, almost two decades after its debut, one of the clearest visual representations of jitter the open-source ecosystem has.

It runs comfortably on a small VPS , ideally placed outside the network you’re monitoring, so you see latency from a real user’s perspective. If you want to fold it into a broader monitoring strategy without handling server maintenance yourself, check out our server administration service or our network section for context on how these measurements tie into the rest of an infrastructure.

The source lives at github.com/zabbix/zabbix , under GPLv2. The company behind it, Zabbix SIA (Latvia), doesn’t run a separate “enterprise edition” with features locked behind a paywall, everything is in the open source version, and revenue comes from support, training and certification. That’s a rare approach in the monitoring market, where “open source” usually means “the stripped-down version of the paid product”.

What Zabbix actually is

Zabbix has existed since 1998, created by Alexei Vladishev, and has gone through several architectural generations to reach its current form. Main components: the Zabbix server (the central engine, processes data and evaluates triggers), an optional Zabbix proxy (collects data locally in a segmented network and forwards it compressed to the server), agents (Zabbix Agent 2, rewritten in Go, active or passive) and a PHP frontend for administration and visualization. Historical data is stored in MySQL, PostgreSQL, or, for large volumes, PostgreSQL with the TimescaleDB extension.

The data model is simple once you see it: an item is a single collected metric (CPU load, free disk space, HTTP response time). A trigger is a logical expression over one or more items that flips a state between OK and Problem. An action defines what happens when a trigger fires: send a notification, run a remediation command, escalate after an interval if nobody acknowledges it. On top of all that sit templates: reusable bundles of items, triggers and graphs, attached to a host class (all Cisco switches, all MySQL servers) and inherited automatically.

Why this matters

Zabbix’s real differentiator is the proxy. When you have a segmented network, a remote site, an isolated VLAN, a secondary datacenter without direct connectivity to the central server, a Zabbix proxy runs locally, collects all the data there, and sends it compressed through a single tunnel to the server. The central server no longer has to open connections to thousands of individual agents; it only talks to proxies. That’s what allows scaling from a few dozen to tens of thousands of monitored devices without redesigning the architecture.

What you get out of the box

• Multiple collection channels: Zabbix Agent 2 (active or passive), SNMP, IPMI, JMX (through a Java gateway), an HTTP agent for webhooks and custom integrations, and calculated items derived from other items.
• Two-level auto-discovery: network discovery (scans an IP range and adds new hosts) and low-level discovery (LLD) for dynamic entities inside a host, filesystems, network interfaces, processes, that appear and disappear over time.
• A large template library, official and community-contributed, for operating systems, network gear from dozens of vendors, and common applications.
• Trigger dependencies, so you don’t get 50 “host down” alerts when what actually failed is a single upstream switch.
• Multi-step escalation actions, with resends and different channels depending on how long a problem has gone unacknowledged.
• Network maps for topology visualization and configurable widget-based dashboards.
• Distributed monitoring through proxies, for segmented networks or very large fleets.

Installing Zabbix on a VPS

The cleanest way to try Zabbix is through Docker Compose, with a PostgreSQL backend:

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: change_me
      POSTGRES_DB: zabbix
    volumes:
      - pgdata:/var/lib/postgresql/data

  zabbix-server:
    image: zabbix/zabbix-server-pgsql:6.4-alpine-latest
    environment:
      DB_SERVER_HOST: postgres
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: change_me
    depends_on: [postgres]

  zabbix-web:
    image: zabbix/zabbix-web-nginx-pgsql:6.4-alpine-latest
    environment:
      DB_SERVER_HOST: postgres
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: change_me
      ZBX_SERVER_HOST: zabbix-server
    ports:
      - "8080:8080"
    depends_on: [zabbix-server]

  zabbix-agent:
    image: zabbix/zabbix-agent2:6.4-alpine-latest
    environment:
      ZBX_HOSTNAME: vps-monitor
      ZBX_SERVER_HOST: zabbix-server

volumes:
  pgdata:

docker compose up -d starts the whole stack. The frontend is on port 8080, and the default login is Admin / zabbix, change it immediately.

For the firewall, with ufw, expose only what needs to be public (ideally nothing, put the frontend behind a reverse proxy):

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw deny 8080/tcp
ufw deny 10050/tcp   # agent port, restricted to the Zabbix server IP only
ufw enable

Port 10050 (passive agent) should only be reachable from the Zabbix server’s or proxy’s IP, not the open internet, ufw allow from <server-ip> to any port 10050. A VPS with 2 GB RAM comfortably runs the server plus frontend for a few hundred hosts; for thousands of hosts, add separate proxies.

Configuration patterns worth knowing

Proxies for segmented networks

If you have a branch office, an isolated VLAN, or a site without direct connectivity to the central server, a local Zabbix proxy solves it without a complicated VPN: the proxy collects everything locally and sends a single compressed stream to the server. It’s also easier on the firewall, one open port instead of hundreds of individual connections.

Low-level discovery for dynamic entities

Instead of manually configuring monitoring for every disk or network interface, LLD periodically scans the host and creates/removes items automatically based on what it finds. When you add a new disk to a server, LLD picks it up on the next run, with no configuration change on your part.

Trigger dependencies to cut the noise

When an access switch goes down, without dependencies configured you get an alert for every host behind it. With a dependency set (hosts depend on the switch’s availability), Zabbix suppresses the derived alerts and shows you a single real problem: the switch.

TimescaleDB for history compression at scale

If you’re storing data from thousands of items over the long term, plain PostgreSQL starts to struggle on space and query performance. The TimescaleDB extension, natively supported by Zabbix, automatically compresses older data and speeds up queries over large ranges.

Where Zabbix is not the right answer

For a homelab or 3-5 VPS instances, Zabbix is clearly overkill. The learning curve (items, triggers, actions, templates, proxies) doesn’t pay off for a small fleet; there, an Uptime Kuma or a Gatus do the job in a few minutes.

The UI is functional, but looks and feels “classic enterprise”, you don’t get the free-form exploration experience Grafana gives you over time-series data. Many teams use Zabbix as a data source, through the official Grafana plugin, precisely to combine Zabbix’s solid collection/alerting engine with modern visual exploration.

It’s also not ideal for ephemeral cloud-native workloads, where containers appear and disappear within seconds. Its discovery model assumes a host exists long enough to be discovered, configured and monitored; for environments where everything is ephemeral, a Prometheus-style model (pull with service discovery built into the orchestrator) fits more naturally.

Alternatives we considered

Checkmk offers a more automated discovery flow out of the gate and a stronger ITIL focus, in exchange for slightly less flexibility in the data model.

Prometheus/VictoriaMetrics + Grafana remain our choice for visual correlation and ad-hoc queries over metrics, we wrote about why we use them in a dedicated article.

Nagios/Icinga remain relevant for teams that want granular ground-up control, but without the native proxy-based scalability Zabbix has.

So, should you run it?

If you administer a large infrastructure, with lots of network gear, branch offices or segmented VLANs, and you want a mature, free system proven at enterprise scale, Zabbix is a solid choice. If your fleet is small, start with something simpler and come back to Zabbix when you grow.

You can start the test on a VPS with us in a few minutes using the stack above, or let our server administration team handle installation, proxies and templates from scratch.

Checkmk attacks exactly that problem. Instead of starting from a blank slate and manually declaring “monitor the /var filesystem on host X”, you point it at a host and it tells you what it found: filesystems, network interfaces, processes, systemd units, Docker containers, whatever is there. The code lives at github.com/Checkmk/checkmk , the Raw edition is open source under GPLv2, and we run it in production ourselves, alongside Grafana and VictoriaMetrics, for service auto-discovery and classic host monitoring in our Bucharest datacenter.

What Checkmk actually is

Checkmk started around 2008 as a plugin called check_mk for Nagios, built to solve the pain of manually configuring checks. Over time the project grew into a full monitoring platform with its own collection engine and its own web interface, but it kept the original philosophy: discover first, configure second.

In practice it works like this: you install the Checkmk agent on a host (a small binary, no heavy dependencies) or configure it to talk SNMP/IPMI/HTTP to a device that can’t run an agent. Then you run discovery, and Checkmk proposes a list of services to monitor based on what it actually found there. You accept the list (or tweak it), and from that point on the host is monitored.

There are two major edition tracks: Raw, fully open source, with a check engine historically based on Nagios-core, and the commercial Enterprise/Cloud editions, which bring a proprietary core (CMC), higher scale, reporting, and a few extra integrations (agent bakery, for example). For most self-hosted infrastructures, Raw is enough.

Why this matters

The difference versus classic Nagios or Zabbix isn’t philosophical, it’s practical: time. With 5 servers you write the config by hand and never notice the cost. With 50 or 500, every new host, every new disk, every reconfigured network interface means a manual edit that someone eventually forgets. Checkmk removes most of that repetitive work: you run discovery periodically, and the differences (new services that appeared, services that vanished) are flagged explicitly, not silently ignored.

What you get out of the box

• Auto-discovery of hosts and services, backed by over 2000 bundled check plugins covering operating systems, network gear from dozens of vendors, databases, hypervisors and common applications.
• Hybrid collection: agent-based wherever you can install a binary, agentless via SNMP, HTTP/API or IPMI wherever you can’t (switches, UPS units, BMCs).
• Rule-based notifications, with flexible routing to email, Slack, an SMS gateway or any custom script, depending on host, severity, or time of day.
• Downtimes and acknowledgements, plus an ITIL-style workflow for problem states (open, acknowledged, closed) and an event console for correlating syslog/SNMP traps.
• Hardware/software inventory, with change history, useful when you need to know what changed on a server between two incidents.
• Built-in graphs and dashboards based on RRD, plus a business intelligence feature that rolls up the state of multiple services into a single “is this business service OK or not” view.

Installing Checkmk on a VPS

The easiest way to try Checkmk is the official Docker image, which bundles a complete “site” (agent, core, UI, RRD store) into a single container:

docker volume create checkmk_data

docker run -d --name checkmk \
  --restart unless-stopped \
  -p 8080:5000 \
  -v checkmk_data:/omd/sites \
  --tmpfs /opt/omd/sites/cmk/tmp:exec \
  checkmk/check-mk-raw:2.3.0-latest

On first start, the container generates an admin password for the cmk site and prints it to the log (docker logs checkmk). The UI is available at http://<vps-ip>:8080/cmk/check_mk/, but in production you put it behind a reverse proxy with TLS (Traefik, nginx, Caddy), you don’t expose it directly.

For the firewall, with ufw:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw deny 8080/tcp
ufw enable

The idea is that port 8080 (or whatever internal app port) is only reachable from localhost/reverse proxy, not directly from the internet. For a small-to-medium fleet, a VPS with 2-4 GB RAM is enough for discovery and monitoring up to a few dozen hosts; beyond that, allocate more memory or consider multiple distributed Checkmk sites.

Configuration patterns worth knowing

Discovery per folder, not per host

Checkmk organizes hosts into folders, and rules (what to monitor, how to notify, what thresholds to use) can be attached at the folder level, inherited by every host in it. Instead of configuring each server individually, you group similar hosts (all web servers, all Cisco switches) into a folder and apply rules once. Discovery runs periodically per folder, and differences from the known state show up as “new/vanished services to review”, not applied silently in the background.

Piggyback data for indirect architectures

A useful technique when you have a machine (a hypervisor, a load balancer) that “knows” more about other hosts than they can learn on their own: Checkmk lets one host push monitoring data on behalf of another host (“piggyback”). A hypervisor can report VM state without each VM needing its own agent installed. The pattern is similar to how we auto-derive Prometheus/VictoriaMetrics scrape targets from our Ansible inventory: the source of truth stays in one place, and everything else is derived from it.

Event console for correlating syslog and SNMP traps

If you’re already receiving syslog or SNMP traps from network gear, Checkmk’s event console can ingest and correlate them with existing hosts, turning a raw log stream into a structured monitoring signal, with matching rules and escalation.

Layered notification rules

Notification rules can chain: a general rule for the whole infrastructure, overridden by specific rules for a group of critical hosts (production databases, for example) that go through a different channel with a different severity threshold. Avoid having a single Slack channel receiving everything, from a disk at 80% to a downed server.

Where Checkmk is not the right answer

If what you want is a correlated, ad-hoc view over high-cardinality metrics (per-request, per-container, per-API-endpoint), Checkmk is not the right tool; that’s where Prometheus or VictoriaMetrics, queried through PromQL and visualized in Grafana, are far more flexible. We wrote about Grafana as a visualization layer in an earlier article.

It’s not a log aggregator either: Checkmk’s log monitoring is useful for simple pattern matching (search for a string, count occurrences), not full-text search over terabytes of logs, where you need Loki or ELK.

Finally, the Raw edition has real limits versus Enterprise: agent bakery (custom agent packaging per host group) and scaling past a few thousand hosts are why larger teams pay for the commercial edition. For a small-to-medium self-hosted fleet, though, Raw comfortably covers the need.

Alternatives we considered

Zabbix is the most direct alternative: equally mature, equally open source, but with a different organizational model (items/triggers/actions instead of automatic service discovery) and a stronger focus on scaling through distributed proxies.

Prometheus/VictoriaMetrics + Grafana remain our choice for time-series metrics and custom dashboards, we detailed why we picked that combo separately. Checkmk and this combo aren’t mutually exclusive: many teams run them side by side, Checkmk for discovery + alerting + ITIL workflow, Grafana for visual correlation and exploration.

Nagios, the direct ancestor, remains a valid option if you want full ground-up control, but the manual maintenance cost is exactly what Checkmk is trying to eliminate.

So, should you run it?

If you administer infrastructure with dozens or hundreds of heterogeneous hosts and network devices, and you want to stop hand-writing monitoring configs for each one, Checkmk is worth installing at least as a weekend proof of concept. Discovery alone, showing you within minutes what services run on a new host, justifies the time invested.

If you want to try it without dealing with installation and maintenance, get a VPS with us and spin up the container above in a few minutes, or let us handle all of it through our server administration service , from install to tuning the notification rules.

ZeroTier is a software-defined networking (SDN) platform, open source for the client and controller side (BSL 1.1 license), with code on GitHub . Unlike WireGuard or Tailscale, ZeroTier doesn’t use the WireGuard protocol: it has its own encrypted protocol, built from scratch for a different purpose, to emulate a full Ethernet switch, not just a point-to-point IP tunnel. We evaluated it as an option for scenarios where Layer 2 matters; in production we run plain WireGuard.

What ZeroTier actually is

A ZeroTier network is identified by a 16-digit hexadecimal ID and behaves, from the perspective of connected devices, as a single virtual Ethernet segment, regardless of how many continents physically separate its members. Every device gets a virtual interface that participates in this segment, with full support for broadcast and multicast, exactly like on a physical switch.

Peer discovery happens through global root servers, called “planets,” operated by ZeroTier as public bootstrap infrastructure. On top of that, you can add your own “moons,” self-hosted relay/discovery servers, for cases where you want more control or redundancy independent of ZeroTier’s infrastructure. The network controller, the one that decides who’s part of the network and what rules apply, can also be self-hosted.

Why this approach matters

The Layer 3 model that WireGuard and Tailscale use is simple and efficient for most cases: IP routing between distinct networks. But there’s an entire class of applications that assume they’re sitting on the same physical network segment: device discovery via UDP broadcast, legacy industrial protocols, LAN games looking for servers via broadcast, management systems that rely on ARP and multicast to find each other. None of that works through a pure Layer 3 tunnel, no matter how well encrypted it is.

ZeroTier solves exactly this problem: by emulating Layer 2, any protocol that would work on a local network also works on the ZeroTier virtual network, even if members are spread across different servers in different countries. It’s the difference between “I have a connection to that server” and “that server is, from every software perspective, in the same room as me.”

What you get out of the box

• Full Layer 2 emulation: working broadcast and multicast over the internet, not just unicast routing.
• 16-digit network ID: a network is identified and administered through a single identifier, easy to distribute to new members.
• Rules engine / flow rules: a rules language that filters traffic inside the virtual network (equivalent to an internal firewall on the emulated segment).
• Global root servers (“planets”) + your own moons: peer discovery without depending 100% on public infrastructure, if you choose to host your own relays.
• Self-hostable network controller: you can run your own server that decides membership, without depending on the ZeroTier Central SaaS console.
• Clients on every major platform, including routers and embedded devices.

Installing ZeroTier on a VPS

Installing the standard client is straightforward on any Linux distro:

curl -s https://install.zerotier.com | sudo bash
sudo zerotier-cli join <network-id>

After joining, the member shows up in the network’s admin list (either in ZeroTier Central or your self-hosted controller) and must be manually authorized before it can pass real traffic, a simple but essential security step.

For a self-hosted network controller on your own VPS (instead of using ZeroTier Central), you run the ztncui service or a similar controller on top of zerotier-one in controller mode:

docker run -d \
  --name zerotier-controller \
  --net=host \
  --device=/dev/net/tun \
  --cap-add NET_ADMIN --cap-add SYS_ADMIN \
  -v zerotier-data:/var/lib/zerotier-one \
  zyclonite/zerotier

The admin interface (either ztncui or the local API on port 9993) should never be exposed publicly. Lock it down:

ufw deny 9993/tcp
ufw allow from <your-ip> to any port 9993 proto tcp
ufw allow 9993/udp

You need a VPS with TUN/TAP support and access to the necessary kernel modules; check our VPS plans for a clean base to run it on.

Configuration patterns worth knowing

Manual authorization is not optional

Never leave a ZeroTier network on auto-authorize in production. Every new device must be explicitly approved in the admin console; otherwise, anyone who finds the network ID (which isn’t a strong cryptographic secret) can request to join.

Use flow rules, not just membership

Being a member of the network doesn’t mean a device should see all traffic. Write explicit rules (ZeroTier’s flow rules language) for internal segmentation, exactly like you’d do with VLANs on a physical network.

Self-host the controller if security requires it

If your internal policy doesn’t allow network membership to be decided by an external SaaS service, run your own controller. It’s officially documented and supported, not a hack.

Your own moons for latency and independence

If discovery through public “planets” adds extra latency, or you want a bootstrap path independent of ZeroTier’s infrastructure, host your own “moons” on servers you control.

Where ZeroTier is not the right answer

If all you need is simple routing between two servers or point-to-point administrative access, the complexity of an emulated Layer 2 network isn’t justified: WireGuard does the job more simply and faster. At large scale (thousands of devices), emulated broadcast and multicast over the internet can themselves become a source of unnecessary traffic if the applications on the network are inherently chatty, a trade-off inherited by any Layer 2 network, physical or virtual.

The BSL 1.1 license is also different from a classic permissive license; check it if you have strict compliance constraints around the type of open-source license accepted in your organization.

Alternatives we considered

• WireGuard : simpler, faster, but strictly Layer 3; the right choice when you don’t need broadcast/multicast.
• Tailscale : same Layer 3 philosophy as WireGuard, but with automatic coordination and SSO; doesn’t solve the Layer 2 need though.
• Physical VLANs/VXLAN over a dedicated private network: if you already have your own infrastructure between locations, a classic VXLAN tunnel can be more predictable than a public overlay SDN.

So, should you run it?

If your real need is “these devices need to behave as if they’re on the same cable,” ZeroTier is one of the few tools that solves this properly, with native Layer 2 support and a solid rules engine for internal segmentation. If your need is just “these servers need to talk to each other securely,” check WireGuard first, it’s simpler to operate and understand.

Want to test a self-hosted ZeroTier controller or a stable network node? Start from a VPS with us, or let us configure it through server administration .

This is exactly the gap managed mesh VPNs fill: Tailscale, ZeroTier and others solve it, but with a trade-off - the control plane (identity, topology, access policy) lives on someone else’s servers. NetBird (netbird.io ) is the open-source project (BSD-3 licensed) that keeps the same peer-to-peer WireGuard model but makes the entire control plane self-hostable: both the management server and the signal server that helps pairs of nodes negotiate a direct connection. We evaluated it as an alternative to the commercial stack for cases where you want a mesh VPN without your network topology living on a third party’s infrastructure.

What NetBird actually is

NetBird builds an overlay network on top of WireGuard: every node (server, laptop, container, phone) gets a cryptographic identity and an IP address from a private range, and traffic between nodes travels, ideally, directly between them, encrypted with WireGuard, without passing through a central hub. The hard part - establishing the connection - uses an ICE-like mechanism (Interactive Connectivity Establishment), similar to what WebRTC uses: nodes first attempt a direct peer-to-peer connection (with NAT hole punching where possible), and if NAT traversal fails (double symmetric NAT, restrictive firewalls), NetBird falls back to a relay server so you don’t end up with no connectivity at all.

The server side is two distinct components, both of which you run on your own infrastructure in the self-hosted setup:

• Management server: tracks nodes, groups, access policies and registration keys. It’s the “brain” of the network.
• Signal server: a signaling channel through which two nodes exchange what they need (WireGuard public keys, connection candidates) before establishing the actual tunnel. It never sees application traffic, only coordinates the handshake.

User identity isn’t reinvented: NetBird plugs into any OIDC/SSO provider (Keycloak, Authentik, Zitadel, Google, and others), so adding or removing a teammate from the network is essentially a matter of managing an account in the IdP you already run.

Why this matters

The difference from a commercial mesh VPN isn’t cosmetic. If the vendor behind the service shuts down, loses your data, or abruptly changes its pricing, a self-hosted control plane means that’s a technical problem you can solve yourself, not a negotiation with a vendor. It comes down to whether the full map of your infrastructure (who talks to whom, what access rules exist) lives on your servers or someone else’s. For teams with compliance requirements, or anyone who simply doesn’t want a critical external dependency on connectivity, that difference is real.

What you get out of the box

• A peer-to-peer overlay network built on WireGuard, with automatic private addressing per node
• NAT traversal via ICE/STUN with fallback to a TURN-like relay when direct traversal fails
• Authentication via SSO/OIDC (Keycloak, Authentik, Zitadel, Google, and others), so you don’t have to build a separate user system
• Group-based access policies (who can talk to whom, on which ports), not just “everyone sees everything”
• Setup keys for automatically registering nodes, useful for scripted provisioning or ephemeral containers
• Cross-platform clients (Linux, Windows, macOS, mobile) plus a CLI for automation
• Written in Go, easy to build and run in a container

Installing NetBird on a VPS

The simplest way to get the self-hosted stack running is the official install script on a dedicated VPS , separate from the nodes you want to join to the mesh. You’ll need your own domain (the management API and signal server are exposed over TLS) and, ideally, an OIDC IdP already configured.

# on a clean Debian/Ubuntu VPS, with a domain already pointing here
export NETBIRD_DOMAIN=netbird.example.com
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started-with-zitadel.sh | bash

# once the stack (management + signal + Zitadel + Caddy) is up,
# add a client node on any machine with:
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://netbird.example.com

The official script brings up the whole stack via Docker Compose (management, signal, a Zitadel IdP if you don’t already have one, and a Caddy reverse proxy for automatic TLS). If you already run an IdP, you can skip the Zitadel component and point management.json at your existing OIDC issuer manually.

On the VPS firewall, you’ll need at minimum:

# HTTPS for the management API and UI
ufw allow 443/tcp
# signal server, if exposed on its own port (by default it rides on 443/gRPC-web)
ufw allow 10000/tcp
# TURN-like relay for NAT traversal fallback
ufw allow 3478/udp
ufw allow 49152:65535/udp

The exact relay port depends on the configuration you chose (external coturn vs. the bundled relay); check docker compose ps after installation to confirm which ports each container actually listens on.

Configuration patterns worth knowing

Access policies, not just connectivity

Out of the box, every node in the network can talk to every other node. The first thing worth configuring is groups (e.g. servers, laptops, contractors) and explicit policies restricting traffic between them. A temporary contractor doesn’t need to see the production database just because they’re on the same mesh.

Setup keys for automated provisioning

If you’re adding nodes via Ansible or cloud-init - exactly the scenario of a freshly provisioned VPS - use an expiring, usage-limited setup key instead of authenticating each machine manually through a browser. The key is generated from the UI or API and passed as an environment variable to netbird up --setup-key ....

Relay as a safety net, not the default path

If you notice most connections falling back to relay instead of direct peer-to-peer, check the NAT and firewall on both ends. A permanent relay means extra latency and a dependency on your relay infrastructure for every connection, precisely what you wanted to avoid by choosing a peer-to-peer mesh in the first place.

The signal server is not a trust boundary for traffic

It’s easy to wrongly assume the signal server sees application traffic. It doesn’t: it only brokers the WireGuard handshake. That simplifies the threat model, but it’s worth spelling out clearly when explaining the architecture to a team or auditors.

Where NetBird is not the right answer

If you only need 2-3 servers connected point-to-point and don’t want to maintain another stack (management + signal + IdP), plain wg-quick is simpler and has fewer moving parts that can break. NetBird earns its keep once the node count grows or you need granular access policies and fast onboarding/offboarding through SSO, not for a static handful of nodes.

Self-hosting also means you’re responsible for the availability of the management and signal servers: if both go down, already-connected nodes keep their existing WireGuard tunnels, but you can’t add new nodes or change policies until the stack is back up. It’s worth having a backup plan for the management database.

Alternatives we considered

• Tailscale : the same peer-to-peer WireGuard model, but the control plane is SaaS (there’s also a self-hosted coordination server, Headscale, maintained by the community rather than Tailscale Inc.)
• Headscale : an open-source, unofficial reimplementation of the Tailscale control plane; good if you want the Tailscale client with a self-hosted server
• ZeroTier : a mesh VPN with its own protocol (not WireGuard), a layer-2 overlay, with a self-hosted controller option

So, should you run it?

If you’ve already outgrown a handful of manually managed WireGuard peers and want to keep full control over topology and identity, NetBird is a solid choice: it’s open-source, built on WireGuard (so the cryptography is well-vetted and stable), and self-hosting the entire control plane means you don’t depend on the uptime or pricing decisions of an external vendor.

The stack (management, signal, optionally coturn, and an IdP) runs comfortably on a dedicated VPS with modest resources for small-to-medium teams. If you want it in production but don’t want to own all the maintenance yourself (patching, backups for the management database, monitoring the signal server), take a look at our server administration service, or our network section for context on the kind of infrastructure such a stack would run on.

Tailscale is a mesh VPN network built on top of the WireGuard protocol. The clients are open source (BSD-3 license), but the control plane that coordinates nodes is a proprietary SaaS service. At DreamServer we run plain WireGuard with wg-easy for our own needs; we evaluated Tailscale as an alternative for teams that want zero-config and don’t want to manage keys by hand.

What Tailscale actually is

Under the hood, every data packet still travels over WireGuard: the same cryptography, Curve25519 and ChaCha20-Poly1305, the same point-to-point tunnel principles. The difference is what happens around that core. Tailscale runs a coordination server (control plane) that knows the identity of every device, automatically exchanges and refreshes public keys between nodes, and decides which nodes are allowed to talk to each other based on the policies you define.

Actual data traffic tries to stay peer-to-peer, direct between the two endpoints, even if both are behind different NATs. When a direct connection can’t be established (strict symmetric NATs, aggressive corporate firewalls), Tailscale falls back to its own relays called DERP (Designated Encrypted Relay for Packets), which route end-to-end encrypted traffic without being able to read it.

Why this approach matters

The real problem Tailscale solves isn’t encryption, it’s coordination. Plain WireGuard requires every peer to know the other’s public key and IP/port in advance. In a static network of 2-3 servers, that’s trivial. In a dynamic network with users connecting from different networks every day, it becomes an operational nightmare. Tailscale moves that problem to a central server that handles auto-discovery and key distribution, and users authenticate via SSO (Google, GitHub, Okta, Microsoft) instead of receiving a config file over Slack.

What you get out of the box

• MagicDNS: every device on the network gets a stable DNS name (server1.tail-scale.ts.net), no more editing /etc/hosts.
• Declarative ACLs: a JSON/HuJSON file defines who can talk to whom, on which ports, far more granular than AllowedIPs.
• Native SSO: login through the identity providers you already use, with instant revocation when an employee leaves the organization.
• Automatic NAT traversal: no more manual port forwarding on a router for every new node.
• Exit nodes and subnet routers: a single node can expose an entire subnet or act as an exit gateway for all traffic, without reconfiguring the rest of the fleet.
• Clients on every platform, including mobile, with a simple GUI.

Installing Tailscale on a VPS

Installing the client is minimal regardless of distro:

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --ssh --accept-routes

The tailscale up command opens an authentication link in a browser (or prints one in the terminal for headless servers), where you log in with your identity and authorize the node. For a server that needs to expose an internal subnet to other nodes on the network:

tailscale up --advertise-routes=10.0.0.0/24 --advertise-exit-node

The tailscale0 interface automatically gets an address from the 100.x.x.x space (CGNAT range, reserved by Tailscale). You don’t need a publicly exposed admin port, but if you run an additional local daemon or an exit node with extra services, lock them down explicitly:

ufw default deny incoming
ufw allow in on tailscale0

For a stable coordination node (subnet router, exit node) you need a VPS with predictable uptime; check our VPS plans if you want to run it on our infrastructure.

Configuration patterns worth knowing

ACLs actually need to be written, not just enabled

Without explicit policies in the ACL file, Tailscale defaults to permissive (every node on the tailnet can talk to every other node). For any production environment, write explicit policies like “group X can only reach tag Y on port Z” before adding real users to the network.

Tag devices, don’t rely on user identity

Authorize servers based on tags (tag:prod-db, tag:ci-runner), not on the account of the user who originally enrolled them. If that user leaves the organization and you revoke their access, tagged servers stay functional.

Keep exit node separate from subnet router

Don’t combine, without reason, the exit-node role (all of a client’s internet traffic routes through that node) with the subnet-router role (exposes an internal subnet). They’re different use cases, and enabling them on separate nodes avoids a single point through which everything flows.

Check DERP if latency seems high

If you notice unexpectedly high latency between two nodes, check tailscale netcheck to see whether the connection fell back to a DERP relay instead of going direct. That’s a sign NAT traversal failed, usually because of an aggressive corporate firewall on one side.

Where Tailscale is not the right answer

The most important trade-off, stated plainly: Tailscale’s control plane is proprietary. If your internal policy requires all network infrastructure to be fully self-hosted, or you operate in an environment where you can’t accept an external dependency for access coordination, plain Tailscale doesn’t qualify. Headscale exists, an open-source reimplementation of the control plane compatible with official Tailscale clients, but it requires you to operate and maintain that server yourself.

For very small, static networks (2 servers that never change), it’s also not worth the added complexity: plain WireGuard stays easier to understand end to end.

Alternatives we considered

• Plain WireGuard (with wg-easy for a UI): no external dependency, ideal for small or static networks where you want full control.
• Headscale : open-source control plane, compatible with Tailscale clients, for anyone who wants the functionality without the SaaS.
• ZeroTier : alternative with native Layer 2 support, its own protocol, its own control-plane model (partially self-hostable via “moons” and self-hosted controllers).

So, should you run it?

If you have a distributed team, devices connecting from different networks every day, and you want to avoid manually maintaining WireGuard keys and configs, Tailscale is worth trying: the free tier for personal use is generous, and setup is, literally, a tailscale up and a login. Just be aware of the trade-off: the control plane is SaaS, not yours, and if that’s a problem, Headscale or plain WireGuard remain the options that give you full control.

Need a stable node for an exit node or subnet router? Start from a VPS with us, or let our team configure it through server administration .

WireGuard is an open-source VPN protocol and implementation, GPLv2-licensed for the Linux kernel side, created by Jason A. Donenfeld. Its code lives directly in the Linux kernel (mainline since version 5.6), which makes it both extremely fast and extremely small: a few thousand lines of code, compared to the tens of thousands in the OpenVPN or IPsec stacks.

What WireGuard actually is

WireGuard isn’t a “VPN framework” with dozens of operating modes, optional ciphers, and negotiation combinations. It’s a protocol with a single, fixed cryptographic suite: Curve25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing. There’s no “downgrade” option to a weaker cipher, because there are no options at all. All traffic rides over UDP, no TCP-in-TCP handshake and none of the latency problems that brings.

Why this approach matters

OpenVPN and IPsec were designed 20+ years ago, when flexible algorithm negotiation seemed like a good idea: systems evolved, ciphers changed, you needed to be able to choose. In practice, that flexibility became attack surface. Every configuration option is a decision an administrator can get wrong, and every legacy compatibility mode is code that has to be audited and maintained. WireGuard chose the opposite: one correct path, no switches. The result is a codebase small enough for a single person to read and understand in a weekend, which is precisely what made a formal protocol audit possible before it entered the kernel.

The routing model is just as simple: each peer is identified by a public key, and the routing table is, in effect, a mapping between public keys and allowed subnets (“cryptokey routing”). No certificates, no PKI, no certificate revocation at 3 AM because something expired. You either have the peer’s public key, or you don’t.

What you get out of the box

• Transparent roaming: a client that changes IP (moving from WiFi to mobile data) doesn’t lose the tunnel; WireGuard rediscovers the endpoint on the next valid packet.
• Silence when idle: if no traffic is flowing, WireGuard doesn’t send constant heartbeats, which makes it quieter on the network and friendlier to battery life on mobile.
• Near line-rate performance: in-kernel encryption removes the user-space/kernel-space context switches OpenVPN pays for.
• Declarative configuration: a peer is a few lines (PublicKey, AllowedIPs, Endpoint); no CA, no separate authentication server needed.
• Native cross-platform support: Linux kernel module, WireGuard-go userspace for BSD/macOS/Windows, official mobile clients.

Installing WireGuard on a VPS

The fastest way to get a working WireGuard server with a web UI and QR config generation for mobile clients is wg-easy , an open-source project that puts a dashboard on top of wg-quick:

mkdir -p ~/wg-easy && cd ~/wg-easy
docker run -d \
  --name wg-easy \
  -e WG_HOST=<public-server-ip> \
  -e PASSWORD_HASH='$2a$12$...' \
  -v ~/wg-easy/etc-wireguard:/etc/wireguard \
  -p 51821:51821/tcp \
  -p 51820:51820/udp \
  --cap-add NET_ADMIN \
  --cap-add SYS_MODULE \
  --sysctl net.ipv4.ip_forward=1 \
  --sysctl net.ipv4.conf.all.src_valid_mark=1 \
  --restart unless-stopped \
  ghcr.io/wg-easy/wg-easy

The admin port (51821/tcp) should never be open to the whole internet. Lock it down to the IPs you actually administer from:

ufw allow 51820/udp
ufw deny 51821/tcp
ufw allow from <your-ip> to any port 51821 proto tcp

If you prefer a manual setup (no UI), a clean VPS with wireguard-tools installed and a few lines in /etc/wireguard/wg0.conf gets you running in under 5 minutes. Either way you need a VPS with a modern kernel and root access; check our VPS plans if you want to start from scratch on our Bucharest infrastructure.

Configuration patterns worth knowing

AllowedIPs does double duty

The AllowedIPs field has two roles: besides telling the kernel what traffic to route through the tunnel, it also defines what packets are accepted from that peer (source filtering). If you want split-tunnel (only traffic to your internal network goes through the VPN), put only that subnet there, not 0.0.0.0/0.

PersistentKeepalive for clients behind NAT

If a client sits behind symmetric NAT (common on mobile networks or CGNAT), set PersistentKeepalive = 25 on the client side to keep the NAT mapping open. Without it, the server may try to send traffic to an endpoint that no longer responds.

One key per device, never shared

Generate a separate keypair for every device/peer. It’s tempting to reuse one config between a laptop and a phone, but you lose the ability to revoke a single device’s access without affecting the rest.

MTU matters more than it looks

Over PPPoE or other tunneled links, the default MTU can cause silent fragmentation. Lower the WireGuard interface MTU to 1420 (or even 1280 for maximum compatibility) if you see connections stalling only on large transfers.

Where WireGuard is not the right answer

WireGuard is a point-to-point tunnel protocol, not a fleet management platform. It has no native ACLs, no SSO, no central dashboard showing who’s connected where, beyond whatever you build on top (like wg-easy). If you need per-user access policies, Google/Okta integration, or centralized management across dozens of offices and hundreds of users, you’ll either build that layer yourself or pick a tool that already ships it.

Also, if you need Layer 2 networking (broadcast, multicast, device discovery like on a physical switch), WireGuard isn’t a fit: it’s strictly Layer 3, IP routing.

Alternatives we considered

• Tailscale : built on top of WireGuard, adds automatic key coordination, NAT traversal with DERP relays, SSO, and ACLs. Very easy to get started with, but the control plane remains a proprietary SaaS (Headscale exists as an open-source control-plane alternative).
• ZeroTier : software-defined network that emulates an Ethernet switch over the internet, with Layer 2 support, its own protocol (not WireGuard).
• Classic OpenVPN/IPsec: still relevant where you already have infrastructure built on them, or need compatibility with legacy hardware that doesn’t support WireGuard.

So, should you run it?

If you need a fast, auditable, easy-to-understand point-to-point tunnel between offices, servers, or for administrative access to your infrastructure, WireGuard is the right choice in 2026. We actually run it ourselves: wg-easy sits on our docker hosts, plus a dedicated WireGuard VPN for operational access into our internal infrastructure, precisely because we don’t want to depend on a CA that can expire at the worst possible moment.

If you want to run it on your own infrastructure, start from a VPS with a modern kernel, or let us configure and maintain it through server administration .

This is where we will publish promotions, campaigns, tutorials, recommendations and technical articles about the hosting services we run. If it helps a customer configure, deploy or troubleshoot a dedicated server, VDS or VPS, we want to write it down here.

What to expect

• Promotions and campaigns - when we launch a deal, drop a price, bundle a service or open a new configuration, you will read it here first.
• Tutorials - step-by-step guides with commands you can paste and configuration files you can reuse, focused on getting your servers up and running the way you actually want them.
• Recommendations - platforms, control panels, operating systems and applications that work well on our infrastructure, and how to pick between the usual alternatives.
• Technical articles - dedicated server setup, VDS and VPS management, Linux administration, networking, storage, backups and security hardening - the same topics that come up in our support tickets, written up once so you can find the answer faster next time.

How we write

Honest, source-linked, no fluff. When something needs proof we cite the documentation, the RFC or the vendor knowledge base. When we make a mistake we correct it inline with a dated note.

Stay in touch

• RSS - subscribe in your feed reader at /en/blog/index.xml .
• Email - contact@dreamserver.ro for sales, noc@dreamserver.ro for network operations, or open a ticket from the client area .
• Services - browse dedicated servers , VPS and VDS .

Thanks for stopping by. More posts coming soon.