Images, and what happens after the first boot
Debian 13 is the default because it is the one that surprises people least. Everything else we ship is one click away, custom ISO works at all 34 sites, and nothing inside your instance is touched by us unless you have asked for it in writing.
The catalogue, in full
Every image is a minimal install with our cloud-init configuration and nothing else added. No agent, no monitoring daemon phoning home, no vendor repository you did not ask for.
Images are rebuilt monthly against upstream, so a fresh install is not four hundred packages behind.
| Family | Images | Notes |
|---|---|---|
| Debian | 13 Trixie, 12 Bookworm | Trixie is the default on every plan |
| Ubuntu | 24.04 LTS, 22.04 LTS | LTS only. Interim releases install from ISO if you insist |
| Enterprise Linux | AlmaLinux 10 and 9, Rocky Linux 10 and 9 | Both track the same upstream. Pick by habit |
| Fedora | 42 | Rebuilt within a fortnight of each release |
| Rolling | Arch Linux, openSUSE Tumbleweed, Gentoo | Gentoo arrives as a prebuilt stage 3, not a nine-hour compile |
| Small and unusual | Alpine 3.22, NixOS 25.05, Devuan 5 Daedalus | NixOS accepts a flake through cloud-init at first boot |
| BSD | FreeBSD 14.3, OpenBSD 7.7, NetBSD 10.1 | Full installs on their own disk, not a jail wearing a costume |
| Windows | Server 2025, 2022 and 2019 Standard | Licence billed at 22 euro per month, per instance |
| Hypervisor | Proxmox VE 8 | Bare metal and EPYC from E-32 upward |
| Your own | Custom ISO, any | Upload it or give us a URL. Every site supports it |
Reinstalling is destructive and takes about ninety seconds on a Linux image. Take a snapshot first if there is anything on the disk you have not written down somewhere else.
cloud-init, and what the first boot does
Every Linux image and FreeBSD ship with cloud-init reading a local datasource. Paste user-data at order time and the instance comes up already configured, which is the difference between deploying a server and building one.
- 01
You paste user-data
A cloud-config document or a shell script, in the configurator or through the API. Keys, packages, users, sysctls, a systemd unit, whatever you would otherwise do by hand at the console.
- 02
The instance is created
Median forty-seven seconds from settled invoice to credentials. Networking is written statically into the image at build time, so there is no wait for a lease that may not arrive.
- 03
cloud-init runs once
SSH keys land, the hostname is set, your modules execute in order. Failures are visible in the console log rather than being swallowed, which matters more than it sounds.
- 04
Credentials arrive by mail
A root password for the first login, which you should replace with a key and then disable. Supply a key in user-data and password authentication is off before the instance ever answers on port 22.
- 05
Nothing runs after that
No agent stays resident, no configuration is reapplied on reboot, and nothing of ours polls the instance from outside. What you build is what stays there.
OpenBSD and NetBSD do not ship cloud-init and we have not bolted one on. They take a boot script instead, documented in the knowledge base, which is the approach both projects would prefer you take anyway.
Custom ISO, and running your own hypervisor
If the image you want is not in the list, bring it. Upload the ISO through the panel or give us a URL to fetch, then install through the console exactly as you would on a machine in front of you.
Custom ISO is available at all 34 sites, including the pre-order one.
Upload or fetch by URL
Up to 8 GB per image, kept for thirty days and reusable across your instances. Checksums are shown after upload so you can confirm the bytes that arrived are the bytes you sent.
Install through the console
VNC and serial are included at no cost. A custom install is a manual process and takes longer than a template deployment, usually landing inside the hour rather than inside the minute.
Nested virtualisation, on request
Enabled on EPYC from E-32 upward and on all bare metal. It costs some performance in the guest, which is why it is opt-in rather than the default.
Proxmox VE 8 as a supplied image
For anyone who wants their own hypervisor without installing one. Storage layout and bridge configuration are yours from the first boot; we do not manage what runs inside it.
On metal, none of this applies
You get IPMI, virtual media and the machine. Partition it, install what you like, run a hypervisor of your own choosing, and we will not have an opinion about any of it.
Windows, and the BSDs
Two categories that get one sentence on most hosting sites. Both work properly here, and both have caveats worth reading before you order.
Windows Server, licensed properly
Server 2025, 2022 and 2019 Standard, licensed per instance at 22 euro a month on top of the plan. Bringing your own licence is possible where your agreement permits it on shared infrastructure, which is a question for your reseller rather than for us. Four cores and 8 GB is the sensible floor; two cores and a Windows GUI is an experience nobody enjoys.
The BSDs, as real installs
FreeBSD 14.3, OpenBSD 7.7 and NetBSD 10.1 on their own disks with the platform’s virtio drivers already in place. Only the first of those takes cloud-init; the other two take a boot script. ZFS works exactly as you expect, on top of NVMe that is already mirrored underneath it, so plan your redundancy once rather than twice.
What neither gets
No managed patching unless you buy the hardening add-on at 39 euro a month, no licence for anything beyond the Windows base, and no support for application-level problems inside either. We keep the platform underneath correct and leave the operating system to you.
What we patch, and what is yours
Everything below your instance is our responsibility and gets patched on our schedule. What runs inside it is yours, and we do not log into it. There is no third category.
The dividing line is the virtual machine boundary, and it does not move.
Ours: hypervisor and host kernel
Patched continuously, with live migration used wherever the fix allows it. Where a reboot cannot be avoided you get at least five days of notice and a window you can move once.
Ours: firmware and microcode
System firmware, controller firmware, drive firmware and CPU microcode, tracked across the fleet and rolled out in stages. Speculative-execution mitigations are on by default and we do not offer to turn them off for benchmark numbers.
Ours: the network and its filtering
Edge configuration, filtering rules and the scrubbing layer, changed through review and logged. Anything with customer-visible risk appears on the status page before it happens rather than afterwards.
Yours: everything inside the instance
Kernel, packages, configuration, your application and your own firewall. We have no agent inside your machine and no credentials for it, which is deliberate and occasionally inconvenient for both of us.
Optional: managed hardening
Thirty-nine euro a month buys a baseline we build, patch and monitor for drift, with a report when something moves. It is the only circumstance in which anyone here has access to your instance.
Images are rebuilt monthly, which affects new deployments only. An instance you created in March receives nothing from us in April; running the package manager remains the oldest unglamorous duty in this business.
Questions about images
Yes, through custom ISO, at any site. Upload it or hand us a URL, then install through the console. If it boots on a virtio machine with a serial console, it runs here.
About ninety seconds for a supplied Linux image, a few minutes for Windows, and however long the installer takes for a custom ISO. The disk is wiped either way, so snapshot anything you care about first.
Only what you asked for: snapshots you created, backups you enabled. When an instance is destroyed the storage is released and overwritten before it is handed to anyone else.
Usually, yes, and for the obvious reason: much of what people run on Windows is single-threaded and cares about clock speed more than anything else. Four cores minimum, and give it more memory than you think it needs.
Containers work on any plan without special settings. Nested virtualisation needs enabling, which we do on EPYC from E-32 upward and on all bare metal, on request and at no cost.
No. The fleet is x86-64 and there is no ARM hardware in it, so an ARM image would be emulation pretending to be a server. When that changes it will appear on the changelog.
Pick an image, paste your user-data, pay in coin
The configurator takes both in the same step, and the credentials land in your inbox a median of forty-seven seconds after the invoice settles.