Managed vs unmanaged hosting

The definitions

Managed hosting means the provider takes responsibility for the operating system and, often, the software stack on top: patching, monitoring, backups, security hardening, sometimes the web server and database configuration. You pay more, and you usually accept their choices about versions and tools.

Unmanaged, or self-managed, hosting means the provider supplies a working virtual machine and the platform around it. Everything from the kernel upwards is yours. You pay less and choose everything.

FastNode is self-managed. That's a deliberate fit for developers who already run Linux and would rather not pay for someone to guess at their configuration.

The line, item by item

What a good support ticket looks like

Platform tickets get resolved quickest when they arrive with evidence. Include:

• The server's IPv4 address.
• What you expected and what happened, with timestamps in UTC.
• What you've ruled out: "console shows a login prompt", "mtr from two networks loses packets at the last hop", "rescue mode boots, root filesystem mounts cleanly".
• Output, pasted as text rather than screenshots, so it's searchable.

# useful to attach for a network report
mtr --report --report-cycles 100 YOUR.SERVER.IP
# and from inside the server
ip -br addr; ip route; ss -tlnp

Email [email protected] or open a ticket in the portal.

The work you take on

Self-managing a server isn't a heroic undertaking, but it isn't zero either. Expect to:

1. Harden on day one. Key-only SSH, a non-root sudo user, a host firewall. The SSH hardening guide and the first-hour checklist cover it in under an hour.
2. Automate security updates. unattended-upgrades on Debian and Ubuntu, dnf-automatic on AlmaLinux and Rocky. Then schedule reboots for kernel updates.
3. Watch the basics. Disk space, memory, failed systemd units, certificate expiry. A small external uptime check on top.
4. Back up beyond the platform. Use portal snapshots and scheduled backups, and keep an independent copy of data you can't recreate.
5. Keep the setup reproducible. A shell script, Ansible, or a well-commented runbook means a reinstall is routine rather than archaeology.

# Debian/Ubuntu: automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# AlmaLinux/Rocky
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

When you should pay for managed instead

Be honest about your situation. Choose a managed service if:

• Nobody on the team is comfortable on a Linux shell, and nobody wants to learn.
• Your contracts require someone else to be accountable for OS patching and monitoring.
• Downtime caused by a misconfiguration would hurt more than the extra monthly cost.
• You'd rather spend the hours on your product than on journalctl.

There's no shame in that. Running servers is a skill and a time commitment. We'd rather you pick the right model than buy a FastNode server and resent it.

Response expectations

Platform faults get priority because they affect more than one customer. Questions about your own stack get a pointer when we have one, and a plain "that's outside what we support" when we don't. We'd rather be clear early than string you along with vague replies while your service stays down.

A middle path

Plenty of small teams self-manage with a light touch: a single well-understood image, Docker Compose for services, automated updates, external uptime checks and a monthly restore test. That covers most risk at a fraction of managed pricing. Start on a Spark to practise, then move up once the routine feels boring. Boring is the goal. See what the portal handles for you.