Install on your own hardware

This path gives you full physical ownership: a machine in your home, running your suite, with no monthly bill. You download one file, write it to a USB stick, and boot the spare machine from it once.

What you download is not an installer — it is a finished server. The machine was installed and tested in our build pipeline, and you flash the result, so nothing is decided on your hardware and nothing is downloaded while you wait. It copies itself onto the internal disk in a few minutes, with no network needed.

Inside it is a stock Ubuntu Server 24.04 LTS with My Own Suite installed on top — an ordinary Linux machine you fully control, not a locked-down appliance.

Use a dedicated machine

This erases the disk you pick on the machine you boot it on. It lists every disk it could install onto, says what is already on each one, and makes you choose and confirm — but do not use your everyday computer, and be certain about which disk you point it at.

What you need

• The server-to-be: a 64-bit PC, mini PC, or old laptop with 4 GB+ RAM and firmware set to boot in UEFI mode (not legacy/CSM). More than one internal disk is fine — the installer asks which one to use. Old machines work well — this is a great second life for retired hardware.
• A USB stick: 8 GB or larger (it will be overwritten).
• Your everyday computer, plus a free utility to write the stick: balenaEtcher on Windows, macOS or Linux — it reads the compressed download directly. Rufus also works on Windows if you decompress the file first and choose DD mode. Nothing else is needed.

Get the image

1. Download the image. Open the latest release and use the download link at the top of the notes. It is about 2 GB.

2. Check it arrived intact. The release page shows a SHA256 line. Compare it against your copy:

   • Windows: certutil -hashfile my-own-suite-vX.Y.Z.img.xz SHA256
   • macOS / Linux: shasum -a 256 my-own-suite-vX.Y.Z.img.xz

   They must match exactly. This takes a minute and is worth doing — you are about to let this file install an operating system.

3. Write it to the stick with balenaEtcher. Select the .img.xz file as it downloaded; there is no need to unzip it.

The image contains no password

Every download is identical, so it cannot contain a password — anyone with the file would have it. Your server generates its own login the first time it boots, and hands it to you once. That happens during install, below.

Prefer to build it yourself?

Everything is open source, so you can produce the same image from the repository instead of trusting a download. It is built by installing a machine inside a VM and snapshotting it, so you need hardware virtualisation — Hyper-V on Windows, or KVM on Linux — plus Git, Node.js 22, and Docker Desktop:

git clone https://github.com/rpuls/my-own-suite.git
cd my-own-suite
npm ci
./image-builder/bake.sh all          # Linux; on Windows: .\image-builder\build-image.ps1

The result lands in image-builder/.work/out/. The build boots the image it produced and refuses to finish unless Suite Manager answers on it, which is the same gate the published download passes. See image-builder/README.md for the stages and options.

Install the server

1. Connect a monitor and keyboard, and plug the machine into your router with a network cable if you can. You need the screen for one confirmation and to read your suite’s address afterwards.

2. Boot from the USB stick. Plug it in, power on, and open the boot menu — usually by tapping F12, F2, or Del right after power-on (the exact key flashes on screen or is in the machine’s manual). Pick the USB stick.

3. Pick the disk by number, then type ERASE. The machine lists every disk it can install onto, with what each already holds — empty - no partitions, or NOT EMPTY and the filesystems it found — plus a last option to run from the stick without installing. Confirming is the point of no return for that disk’s contents, and the confirmation names the disk and its contents again. Anything the machine does not recognise simply asks again, so a typo cannot start or abandon an install.

4. Remove the stick and reboot when it tells you to. It copies itself across in a few minutes, with nothing downloaded and nothing to answer.

5. Read your suite’s address off the screen. The machine gives itself an identity and its own server login, then shows a screen with its network address (something like 192.168.123.45) and the ways to reach it.

6. Reserve that address in your router. Give the machine a fixed address — routers usually call it a “DHCP reservation”. Both ways of reaching your suite point at this address, so if it changes later, your links and your apps stop working until you fix them. Do this before anything else.

7. Open your suite. Two addresses reach it and the server’s own screen shows both. Neither is a setting; pick whichever suits your network.

   • http://home.mos.home/ — add a wildcard DNS rule *.mos.home → 192.168.123.45 in your router, AdGuard Home, or Pi-hole. Nothing about your suite ever leaves your network. Many consumer routers cannot express a wildcard rule at all; if yours can, this is the door to take. Just one computer? Add 192.168.123.45 home.mos.home to its hosts file instead, plus one line per app you install later.
   • http://home.192-168-123-45.local.myownsuite.org/ — your server’s address with dashes instead of dots. Nothing to set up, and it works on every device including phones. The name is public but what it points at is not, so nobody outside your home can reach your suite through it — how this works covers what does and does not leave your network. It stops being served if you later add your own domain with HTTPS.

   Create your owner account on the page that opens.

8. Save the server login. Once you are signed in, Suite Manager shows a Save your server login panel. This is the login for the machine itself — its screen and SSH — generated by your server on its first boot. It is the way back in if the suite ever stops responding. Copy it into your password manager, then confirm you have saved it: MOS deletes its copy and clears it from the server’s screen. The same login is also shown on a monitor plugged into the server, if you would rather read it there.

Continue with Your first sign-in.

Good to know

• Nothing is erased unless you choose it and confirm it. Booting the stick does not start an install on its own. On a machine with several disks the installer never guesses: it lists them in a stable order, marks which are NOT EMPTY and with what, and erases only the one you pick and confirm by name.
• If you choose not to install, the machine runs from the stick. That is deliberate — it is how you try MOS without committing a disk, and how you reach a suite when the internal disk has died — but nothing is installed, so the machine stops booting the moment you unplug the stick. The screen says so on every boot when this is the case.
• The machine must boot in UEFI mode. The image ships one disk layout, decided when it was built, and legacy/CSM firmware cannot boot it. If a machine refuses to boot the stick, check that Secure Boot’s CSM/legacy option is off — and if it still refuses, load factory defaults in the firmware setup before concluding it cannot: stale settings look exactly like a machine that will not do UEFI.
• Booting it on a machine that already runs MOS does nothing. The image only installs when it is running from removable media, so the same file is both the installer and the installed system.
• The local.myownsuite.org address does not resolve? Some routers and DNS filters — Fritz!Box, OpenWRT, pfSense, Pi-hole, AdGuard Home — refuse answers that point into your own network. It is called DNS rebinding protection, and whether it bites can differ between devices on the same network, because iPhone Private Relay and Android Private DNS send lookups past your router entirely. Use home.mos.home instead, or add local.myownsuite.org to your router’s rebinding exception list.
• This is an unofficial image, not a Canonical product. It is built from stock Ubuntu Server 24.04 LTS, but it is assembled and published by the My Own Suite project, which is not affiliated with or endorsed by Canonical Ltd. Ubuntu is a trademark of Canonical Ltd. Report problems with it here, not to Ubuntu.
• Nothing updates the operating system yet. My Own Suite updates itself and the apps you install; Ubuntu’s own security updates are not applied automatically, and the Updates screen does not cover them. See Updates.
• Keep the server physically secure. The disk is not encrypted today, so anyone who walks off with the machine can read what is on it. Full-disk encryption is planned; until then, treat physical access to the server the way you’d treat physical access to a filing cabinet, and prefer a machine that isn’t easy to pocket. Apps that encrypt data on your device before sending it are unaffected.
• Setup happens over your local network, unencrypted. You create the owner account before any certificate exists, whichever address you used, so do this on a network you trust rather than shared or public Wi-Fi. Adding HTTPS below closes this.
• Some apps need HTTPS before they work at all. A fresh self-hosted suite is served over plain http://, and browsers withhold part of their cryptography from insecure addresses. Password managers are the clearest case — they will not work until your suite has a certificate. If that is what you came for, do the Cloudflare HTTPS setup first. Most other apps are fine on plain HTTP inside your own network.
• Backups: Connect an encrypted USB or external drive directly to the MOS machine; do not keep the only backup on its internal disk. See Back up and restore.
• Next step — a real domain with HTTPS. Own-hardware installs unlock the built-in Cloudflare HTTPS setup: your suite on home.yourdomain.example with a real certificate, still completely private to your home network.