Deploy and Host self hosted Homelable on Railway

Homelable is an MIT-licensed, self-hosted canvas for drawing and documenting a homelab: hosts, VMs, containers, links, racks and docs.

About Hosting Homelable open-source software on Railway (self hosted Homelable template)

Homelable is an MIT-licensed homelab diagram, inventory and documentation canvas.

The template builds both services, connects the frontend to the backend over Railway's private network, and generates the admin password and session secret.

Why Deploy Homelable, the self-hosted homelab diagram and inventory canvas on Railway

Running Homelable on Railway gives you a homelab canvas without maintaining a server. This is independent community packaging of Pouzor/homelable v3.7.1 and is not affiliated with or endorsed by the upstream authors.

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Homelable on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for Homelable self hosting

Homelable is two containers, a frontend and a backend with a volume for SQLite, so the choice is mostly about how much host you want to run.

Provider	What You Get with Railway	What You Get with the Other Provider
DigitalOcean	Two services from the template, a public domain, health checks and a volume, with no server to patch.	A Droplet you secure, update and configure with Docker yourself.
AWS	The same two services with usage-based billing and no VPC or load balancer to build first.	Wide networking control, but you assemble and maintain compute, storage, DNS and TLS.
Hetzner	A managed deploy with the backend on a private network and no host OS to manage.	Low-cost servers where you install Docker, a reverse proxy and backups yourself.

Choose a VPS if you want root access to the host, and Railway if you would rather not run it.

Common Use Cases for hosted Homelable

Mapping a growing homelab: Draw each host, VM, LXC container and the links between them on one interactive canvas, then keep it current as machines come and go.
Racking and cabling the physical side: Use rack canvases to place servers, switches and patch panels in U slots and record which port connects to which, next to the logical diagram.
Annotating the lab with floor plans: Upload a floor plan or room layout as a background and place devices where they physically sit, so cable runs and power locations are easy to find.
Documenting services and procedures: Keep markdown documentation for the lab alongside the diagram, covering runbooks, service notes and the reasoning behind design decisions.
Importing an existing inventory: Bring in Proxmox guests and host details, Unraid layouts, or a hand-written YAML description, then adjust the canvas instead of drawing everything from scratch.

Dependencies for Homelable Docker hosted on Railway

This template runs two services in one project: a public frontend and a private backend. Keep one replica of each, and keep the backend service name as backend so the frontend can reach backend.railway.internal:8080.

Deployment Dependencies for Managed Homelable Service (frontend and private backend)

The frontend is public on port 8080 with health check /.

The backend has three generated or referenced variables, so you enter nothing:

HOMELABLE_ADMIN_PASSWORD (24 characters): admin password, bcrypt-hashed at every boot. Change it and redeploy to rotate.
SECRET_KEY (64 characters): signs login session tokens. Changing it signs everyone out.
CORS_ORIGINS: JSON list defaulting to the frontend's Railway HTTPS domain. Add a custom domain here if you set one.

The frontend has no template variables. The optional upstream MCP service is not included.

Implementation Details for Homelable (unmodified upstream 3.7.1 images plus Railway start scripts)

The frontend is the unmodified upstream image with a Railway nginx layer. nginx listens on 8080 over IPv4 and IPv6 and proxies /api, /ws and /docs to backend.railway.internal:8080, resolving that name at runtime so backend redeploys keep working.

The backend is the unmodified upstream image plus start.sh.

How does Homelable compare against other tools

Homelable vs a Drawing Tool or Wiki (Homelable Alternative)

Live Status and Scanning: Homelable checks node status (ping, TCP, HTTP and more) and can run nmap scans, so the diagram reflects what is online. A drawing tool or wiki shows only what you typed in. On Railway, scans and ping checks cannot reach private homelab IPs.
Inventory and Documentation: Each device carries a document and an inventory entry next to its place on the canvas. Drawing tools are often stronger for polished one-off diagrams.

Homelable vs a Local Docker Compose Install (Homelable Alternative)

Hosting Location: A Railway deploy runs on managed infrastructure, with no host for you to patch. A local Compose install keeps data on hardware you control.
LAN Discovery: A local install on a LAN host can scan and ping private ranges. The Railway template cannot, since SCANNER_RANGES is baked to an empty list.
Setup Effort: The Railway template needs no Docker host of your own, and generates the admin password for you. Compose gives you more control over networking and volumes.

Homelable with Docker vs Railway (Homelable Hosting Comparison)

Network Reach: Docker on a LAN host reaches private addresses directly. Railway reaches only internet-reachable hosts, so build the canvas by hand, import YAML, or use the Proxmox and Unraid importers against those hosts.
Service Layout: The Railway template runs a public frontend and a private backend. Keep the backend service named backend so the frontend can reach backend.railway.internal:8080.
Persistence and Sign-In: Both keep SQLite data on a volume at /app/data, so keep one replica of each service. On Railway, sign in at the frontend domain as admin with HOMELABLE_ADMIN_PASSWORD from the backend Variables tab, since upstream's default admin/admin is never used.

How to use Homelable on Railway?

Open the frontend public domain in your browser and sign in as admin, using the HOMELABLE_ADMIN_PASSWORD value from the backend Variables tab. Do not try upstream default admin/admin, because the wrapper never accepts it.
Remember that Railway is not on your LAN. The nmap scan and ping status checks cannot reach private homelab addresses, so build the canvas by hand, import YAML, or use the Proxmox or Unraid importers against hosts reachable from the internet.
Keep the backend service named backend, since the frontend proxies to backend.railway.internal:8080.
If you add a custom domain, update CORS_ORIGINS on the backend to include it, then redeploy.
Keep SECRET_KEY as generated. Changing it signs everyone out.
Keep one replica of each service, because the backend stores SQLite data on a single volume.

Health endpoints to check after deploy:

frontend: /
backend:  /api/v1/health

How to self host Homelable on other VPS Services (Homelable self hosting guide)

Running Homelable on your own VPS uses the upstream flow: Docker Compose with the frontend and backend images, a data directory for SQLite, and an admin password.

Clone the Repository

Clone the upstream repository onto the host and move into it.

git clone https://github.com/Pouzor/homelable.git
cd homelable

Install Dependencies

Install Docker and the Docker Compose plugin on the host.

Configure Environment Variables

Copy the example file and set your values.

cp .env.example .env

Edit .env and set SECRET_KEY, AUTH_PASSWORD_HASH (a bcrypt hash of your admin password), and SCANNER_RANGES, for example ["192.168.1.0/24"].

Start the Homelable Application

Start the stack and open the frontend on port 3000 of your host.

docker compose up -d

Pricing and License of Homelable (Homelable pricing)

Homelable is MIT-licensed open-source software, so you can self-host it for free and modify it to suit your lab.

Homelable hosted vs self hosted comparison (Pricing, features, costs, and more)

Homelable is free MIT software, and the pinned v3.7.1 release describes no hosted plan.

Monthly cost of self hosting Homelable on Railway

Railway bills by usage, so the monthly total depends on RAM and CPU use, the size of the backend volume at /app/data, and the services you run.

System Requirements for Hosting Homelable on a VPS

Homelable runs as a frontend and a backend container, with SQLite data kept on disk, so a VPS needs enough memory for both and room for that data.

Frequently Asked Questions (FAQs)

How do I sign in to Homelable on Railway?

Open the frontend public domain and sign in as admin with HOMELABLE_ADMIN_PASSWORD from the backend Variables tab. Do not use the upstream default password.

Why do my network scans fail?

Railway is not on your LAN, so the nmap scan and ping status checks cannot reach private homelab addresses, and SCANNER_RANGES is set to empty.

Why must the backend service stay named backend?

The frontend image proxies /api, /ws and /docs to backend.railway.internal:8080, so renaming the backend service breaks that connection.

Is the optional MCP service included in this template?

No.

What should I back up?

Back up the backend volume mounted at /app/data, which holds the SQLite database and uploads, and keep a copy of SECRET_KEY and the admin password.