Written down once, so nobody types it twice.
Everything here started as a ticket. When the same answer went out for the third time we moved it into an article, ran the commands against a fresh instance, and linked it from the reply. That is the whole editorial process.
What is in here
Operational documentation for people who already have root and would like to be finished before lunch. There is no chapter explaining what a server is.
Debian 13 and AlmaLinux 10 unless an article says otherwise. Older releases usually work; the paths move.
Where a command differs between Debian and AlmaLinux, both are given rather than one with a vague note attached. Where something cannot be done at all, the article says so and stops. Nothing here is aspirational.
What you will not find is a tutorial on your own application. We run infrastructure. Configuring your reverse proxy is your business, right up to the point where the packets stop arriving — at which point it becomes ours, and there is an article about that too.
If a command in here fails on a current image, that is a bug in the article and we want the ticket. Quote the slug.
How it is filed
Six categories, chosen because they match the six kinds of ticket we actually receive rather than any tidy taxonomy of hosting.
Getting started
The first hour of an instance: login, cloud-init, API tokens. Read these once and most of the rest becomes optional.
Networking
Addressing, reverse DNS, the routed IPv6 /64, fair-use bandwidth, packet loss, and what happens while you are being attacked.
Storage
Extra NVMe volumes, filesystems, snapshots and restores. Short section, because block devices are not complicated when nobody is overselling them.
Security
Keys, nftables, two-factor authentication. Everything here is something we would do on our own machines.
Billing
Account balance, underpaid invoices, and the timeline between a missed renewal and a destroyed instance.
Operations
Custom media, the out-of-band console, plan changes, site moves, kernel tuning, and steal time that reads zero.
When an article does not answer it
The knowledge base covers what we can write down in advance. Anything specific to your instance, your traffic or your invoice needs a human, and there is one at every hour of the day.
- 01
Check the status page
If a site is having an incident, it is on /status before it is in your inbox. Start there when something worked yesterday and does not today.
- 02
Try the guides
Longer pieces that build something end to end, rather than answering one question. They live at /guides and assume you have read the relevant article here.
- 03
Open a ticket
Median first response is eleven minutes, measured across the last quarter at every hour. Tickets go to engineers, not to a queue that forwards them to engineers.
- 04
Use the console
If the instance is unreachable, the out-of-band console gets you a shell over a path that does not depend on your network being correct. It is included on every plan.
A ticket with an instance ID, a timestamp carrying a timezone and the exact command that failed is answered in one round trip. A ticket that says “my server is slow” is answered with a question.
Getting started
03Security
03Networking
06Storage
02Operations
06Billing
02Ask a human instead
Support is staffed continuously and reads every ticket in the order it arrived. No tier one, no script, no invitation to reboot and try again.