Skip to content

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