# One-click apps and six Linux distributions

*2026-10-16 · VPSNine*

> At launch you can order Docker, WordPress, WireGuard or twelve other apps, on six distributions in ten versions. How it works, and what's unproven.

Source: https://vpsnine.com/blog/one-click-apps-and-six-linux-distributions

Ordering a server at launch was going to mean picking Ubuntu or Debian and getting a bare system. That's still the default. But you'll also be able to pick from six distributions in ten versions, and have one of fifteen apps installed for you on the first boot.

## The distributions

Ubuntu 22.04, 24.04 and 26.04 LTS. Debian 12 and 13. AlmaLinux 9 and 10, and Rocky Linux 9, for software that expects Red Hat Enterprise Linux. Fedora for the newest packages, and Arch for people who'd rather build it up themselves.

Ubuntu 24.04 LTS stays preselected, because it's the right answer for most people. [Choose a Linux distribution](https://vpsnine.com/help/choose-a-distribution) has the support dates for each one and a short guide to picking.

## The apps

Docker, Coolify, nginx with Certbot, Caddy, a LEMP stack, WordPress, Node.js, PostgreSQL, MariaDB, Redis, WireGuard, Tailscale, Uptime Kuma, n8n and a Minecraft server. Each has a page at [vpsnine.com/apps](https://vpsnine.com/apps) saying what gets installed and what to do once it's there. [One-click apps](https://vpsnine.com/help/one-click-apps) has the list with the smallest plan each one needs.

If your favourite isn't on the list, you can name up to 20 extra packages and paste in your own first-boot script with the order. [Extra packages and setup scripts](https://vpsnine.com/help/setup-scripts) has examples. All of it works from the panel, the API and the `vps9` CLI:

```bash
vps9 servers create --plan standard --image ubuntu-24.04 --hostname web-1 --key key_… --app docker
```

## No golden images

The usual way to do one-click apps is a golden image: install the app once, take a copy of the disk, and hand that copy to everyone who orders it. It's fast. It's also a snapshot of whenever someone last rebuilt it, with old packages, old app versions, and sometimes leftovers from the machine it was made on.

We went the other way. Every server boots from the distribution's own official cloud image, the same file Ubuntu or Debian publish for every cloud. We check its checksum and don't modify it. Then cloud-init, the tool those images already include for first-boot setup, installs the app from the project's own repository, or the distribution's.

That has a few consequences we like:

- **It's the real upstream system.** No VPSNine tweaks to find out about later. Distribution guides apply as written.
- **The app is current.** Docker comes from Docker's repository on the day your server boots, not from a disk image built months ago.
- **It's ordinary software.** Updating it, configuring it or removing it works the same as if you'd installed it yourself, because, in effect, you did.
- **We maintain less.** Fifteen apps on ten distribution versions would be dozens of images to rebuild every month. Instead each app is a short install recipe per family.

The cost is time. The server answers SSH within our [59-second target](https://vpsnine.com/blog/what-59-seconds-means), but the app may still be installing. Redis takes seconds. Coolify can take five minutes. `tail -F /var/log/vps9-setup.log` shows you where it's got to (the package installs before it print to `/var/log/cloud-init-output.log`), and a file at `/var/lib/vps9-setup.exit` says whether it worked.

## What we haven't proven

None of this has run on our production hardware yet. The install recipes are written, but we haven't yet run every app on every distribution, on real VPSNine servers, from a real order. Until we have, three things are open:

- **Timings.** How long each app takes on each plan. We'll know once we've measured it.
- **Upstream changes.** Projects change their install steps, and repositories go down for a few minutes now and then. When a recipe breaks, the log will say so, and we'll fix it, but it will happen.
- **The odd pairing.** An app that's fine on Ubuntu and trips over SELinux on AlmaLinux, say. Those are what testing on real hardware is for.

If an app or a distribution isn't ready by launch, it won't be in the order form until it is. We'd rather launch with fewer than ship one that doesn't work.