Deploy on your own hardware

This option is for people who want to run My Own Suite on their own hardware at home or in a private location they control.

It offers the most ownership and the strongest off-grid option, but it also asks the most from you.

Who should choose this?

Choose this if:

• you already have suitable hardware
• you want maximum control over where the suite runs
• you are comfortable taking responsibility for networking, security, backups, and maintenance

Tradeoffs

Compared with Railway or a VPS:

• setup is more advanced
• safe internet exposure requires more care
• uptime and recovery are fully your responsibility

Potential benefits:

• very high ownership
• no digital footprint, you stay fully off grid
• low recurring hosting cost if you already own the hardware
• a strong fit for homelab and privacy-focused setups

Current status

The self-hosting track is now being shaped around a dedicated Ubuntu Server 24.04 LTS flow for small always-on machines such as mini PCs, home servers, and repurposed office hardware.

Today, the maintained stack still lives in the Docker Compose deployment, but the self-host direction is becoming clearer:

• one canonical local suite domain pattern: appname.mos.home
• one canonical public domain pattern: appname.mos.<your-domain>
• one shared host-based routing model across local, VPS, and self-hosted installs
• a dedicated Ubuntu bootstrap track for making first setup less hands-on

What this means in practice

The current local stack already proves the routing model with *.localhost.

For self-hosting on your own hardware, the aim is to keep that same app-per-host pattern instead of introducing a separate URL system just for homelabs.

That means the intended local addresses look like this:

• suite-manager.mos.home
• homepage.mos.home
• seafile.mos.home
• immich.mos.home

And if you later expose the suite through a public domain, the same pattern continues:

• suite-manager.mos.example.com
• homepage.mos.example.com
• seafile.mos.example.com
• immich.mos.example.com

Important limitation

The self-host machine can automate a lot, including Ubuntu setup steps, Docker installation, and the suite bootstrap itself.

What it cannot universally automate is wildcard DNS for the rest of your home network, because that depends on infrastructure outside the suite box itself.

In other words:

• the suite box can make itself easy to install
• your router, AdGuard Home, or another DNS layer still decides how the rest of your devices resolve *.mos.home

That is why the self-host path is being built around:

• a low-friction baseline with a normal machine hostname on the LAN
• an enhanced mode where one wildcard DNS rule makes the full appname.mos.home pattern work across your devices

Recommendation today

If you are new to the project and mainly want to try the suite quickly, start with Deploy on Railway.

If you want the current self-managed route that the self-host flow is building on top of, use Deploy on a VPS.

If you already know you want the suite on your own hardware, the best fit is now:

• Ubuntu Server 24.04 LTS
• the current Docker Compose stack as the runtime base
• a local DNS setup that can eventually point *.mos.home at the suite machine

Installer setup

The current self-host installer flow is built around one simple config file that you fill in before creating the USB installer.

It asks for the small set of values you are most likely to need right after installation:

• owner name
• owner email
• owner password
• Linux password

That matters because it avoids the frustrating situation where the machine finishes installing, but you then have to connect a screen and keyboard just to dig through generated files and discover what password the installer chose for you.

In practice, the flow is:

1. Fill in the installer config file with your chosen details.
2. Build the self-host installer from that config.
3. Boot the target machine from the USB.
4. After installation, sign in with the credentials you chose yourself.

The installer uses that config to seed both the Linux login and the initial Suite Manager owner account.

The USB installer is meant to be bootable, not boot-forcing. The My Own Suite install option is preselected in the boot menu, but the installer should still wait for explicit human confirmation instead of silently starting after a timeout.

On Windows, the ISO builder currently uses Docker to assemble the final installer image. That means Docker Desktop needs to be running before you build the installer.

The temporary plaintext handoff file is only meant to get those values through installation and first boot. After that, it should be removed so the machine is not left with an extra plain-text password file lying around.

Optional advanced email setup

The current self-host direction still builds on the same Docker Compose stack used for the VPS/local path, so advanced users can also reuse the optional shared SMTP setup for compatible apps such as Seafile and Vaultwarden.

This is fully optional and only makes sense if you already understand what an SMTP server is and have access to one.

For the actual technical setup, use the dedicated SMTP guide:

• Optional email with SMTP