Providers and hardware

Which systems, server types and panels server-prep is known to work on, which ones still need a report, and how you can send yours.

What "tested" means here

The README names the tested targets: Ubuntu 22.04, 24.04 and 26.04, and Debian 12 and 13, on cloud VPS and on dedicated / on-premise servers. Those are the only cells marked "tested by maintainers" below.

The README does not say which panel was used on which system. So every panel cell says "needs a report" until someone shares a run. This page is honest on purpose: a gap is more useful than a guess.

• VPS: a virtual server you rent from a cloud provider.
• Dedicated / on-premise: a physical machine, rented in a data center or in your own office.
• Other machines: a laptop or an old PC used as a server, or a local VM (for example with multipass).

See the Glossary for other words.

Compatibility matrix

server-prep + audit means server-preconfig.sh, server-prep.sh and server-audit.sh on that system, with any panel or none.

OS	Server type	server-prep + audit	Coolify	Dokploy	Openship
Ubuntu 22.04	VPS	tested by maintainers	needs a report	needs a report	needs a report
Ubuntu 22.04	dedicated / on-premise	tested by maintainers	needs a report	needs a report	needs a report
Ubuntu 24.04	VPS	tested by maintainers	needs a report	needs a report	needs a report (test planned, #57)
Ubuntu 24.04	dedicated / on-premise	tested by maintainers	needs a report	needs a report	needs a report
Ubuntu 26.04	VPS	tested by maintainers	needs a report	needs a report	needs a report
Ubuntu 26.04	dedicated / on-premise	tested by maintainers	needs a report	needs a report	needs a report
Debian 12	VPS	tested by maintainers	needs a report	needs a report	needs a report
Debian 12	dedicated / on-premise	tested by maintainers	needs a report	needs a report	needs a report
Debian 13	VPS	tested by maintainers	needs a report	needs a report	needs a report
Debian 13	dedicated / on-premise	tested by maintainers	needs a report	needs a report	needs a report (test planned, #57)
any of the above	laptop or old PC	needs a report	needs a report	needs a report	needs a report
any of the above	local VM	needs a report	needs a report	needs a report	needs a report
other Debian / Ubuntu versions	any	needs a report	needs a report	needs a report	needs a report

What exists for each panel today is on the Panels page. In short: Coolify has its own code paths and two guides, Dokploy has a few, and Openship gets its own AIDE and auditd paths and otherwise only changes the name in messages (epic #10).

Planned: a matrix with one row per real run (OS, server type, provider or hardware, panel, version, audit result, notes, link), in #29. Every supported system also runs end to end in CI, in a virtual machine booted from its official cloud image: the latest report shows the result on main (how it works). It does not replace reports from real providers and hardware.

Known quirks by system

These are handled by the scripts today. Each one links to its fix on Troubleshooting.

System	Quirk	What server-prep does
Ubuntu 26.04	uses sudo-rs, which rejects the sudo log file setting	skips the log file; sudo-rs logs to the journal, and the audit counts it as PASS (fix)
Ubuntu with Ubuntu Pro	ESM offers an old CrowdSec 1.4.x	pins CrowdSec to its official repo at priority 900 and upgrades it (fix)
Ubuntu	apport forces fs.suid_dumpable=2	disables apport (fix)
Any system with UFW	/etc/ufw/sysctl.conf turns log_martians back off at boot	rewrites that file (fix)
Fresh Debian	no openssh-server, and only vim-tiny	server-preconfig.sh installs SSH; the update step installs vim (fix)
Minimal installs	cracklib-runtime is missing, so passwd fails	installs it and builds the password dictionary (fix)
Any fresh server	apt runs in the background at boot	waits up to 10 minutes for the apt lock (fix)

Tips per server type

VPS

• Keep the provider's network config. At the network question of server-preconfig.sh, press Enter (keep).
• Find the provider's web console before you start. You need it if SSH breaks.
• Many providers put a cloud firewall in front of the server. Open the new SSH port (822) there too, and keep 22 open until the SSH step is confirmed. Otherwise the server works but you can't reach it.
• Cloud images can add their own file in /etc/ssh/sshd_config.d/. server-prep's 00-server-prep.conf is read first and wins for most settings, but sshd listens on every Port line it reads. So the SSH step comments out the Port lines of /etc/ssh/sshd_config and of the other files, after a backup, and lists those files in its notes.

Dedicated or on-premise

• Save the network so it survives a reboot:

  sudo ./server-preconfig.sh --static-ip current

  The check at the end should say OK <iface> saved as static. A DHCP reservation on the router also works.
• Keep a remote console: IPMI, iDRAC, iLO or KVM, the host's rescue mode, or a screen and keyboard.
• In the BIOS, set Restore on AC Power Loss to Power On.
• Behind NAT, use Tailscale for SSH and the panel, and a Cloudflare Tunnel for the apps.

Laptop or old PC: the laptop step ignores the lid and turns off sleep (LAPTOP_MODE=auto). Never forward port 22 or 822 on your router: use Tailscale.

Beginner notes for each common VPS provider are planned in #19.

Report your result

Every report fills a cell in the matrix. A short "it works" is as useful as a bug report.

Where to post today:

• It works, or works after some manual steps: the Compatibility report issue form. It asks for the fields below.
• You want to show your whole setup: Discussions → Show and tell.
• You have a question: Discussions → Q&A.
• Something is broken: open an issue.
• A security problem: report it privately, as SECURITY.md explains. Never in public.

Planned: a "Compatibility reports" category with a form in Discussions (#26) and a /compat-report skill that turns a report into a matrix row (#44).

What to include

Field	Example
OS and version	Debian 13
Server type	VPS, dedicated, laptop or old PC, VM
Provider and plan, or the hardware	"VPS 2 vCPU / 4 GB at ", "mini PC", "rack server"
Panel and PANEL_ACCESS	Coolify, tailscale
server-prep version	v1.1.1
Audit summary	the output of the command below
What needed manual work	"opened 822 in the provider firewall"

Collect it

Print your OS:

. /etc/os-release && echo "$PRETTY_NAME"

You see one line, for example Debian GNU/Linux 13 (trixie).

Print the server-prep version:

./server-prep.sh --help | head -1

The line starts with server-prep.sh v and the version number.

Write the audit as JSON. This changes nothing on the server:

sudo ./server-audit.sh --quiet --no-txt --no-network --json audit.json

--no-network skips the public IP lookup. Print the summary without your host name and public IP:

jq '{score, summary, fails: [.checks[] | select(.status == "FAIL") | .id]}' audit.json

You get the score, the PASS / WARN / FAIL / INFO counts, and the id of each FAIL check. A prepared server usually shows 0 FAIL. Paste this output in the form's Audit summary field, never the whole audit.json: that file holds the host name and the public IP.

Before you post

• No secrets. Remove every token, key and password: tunnel tokens, CrowdSec enroll keys, Tailscale keys, InfluxDB tokens, Telegram bot tokens.
• Read everything you add by hand. Audit messages, log lines and notes can contain IPs, host names or user names. Replace them with examples such as web-01, example.com or 203.0.113.10.
• Don't paste the whole log from /var/log/server-prep/. It lists IPs and host names, and logs from version 1.1.1 and older can contain the tunnel token (#64).
• Never name a client or a site. Name the provider if you like, and describe the machine in generic words.

Thank you: each report helps the next person pick a setup that works.