Skip to content
Work
HIGHDevOps / self-hosted infrastructure stack01/2025–present

Home setup stack

Docker ComposePaperless-ngxn8nFirefly IIIPostgreSQL (pgvector)Redisnginxautosshpaperless-aiMealieGrocyDashyGotenbergApache TikaTypeScript
github.com/itd24/home-setup

Overview

This is the infrastructure half of my home server. One command starts the database, the automation engine, the document archive, the finance tools, the recipe and stock apps and the reverse proxy.

I did not want a pile of separate installs, so everything lives in one Docker Compose project. One PostgreSQL instance serves all of it. A small setup script gives every service its own database and its own owner, so the tools stay apart without more servers to look after.

My own code is not copied into this repository. The API, the dashboard and the proxy container sit in their own folders and get mounted in. That way I can change one of them without

Problem

My household had paper documents, bank data, recipes and stock lists spread over different tools and folders. I wanted one home server that runs all of it, starts with one command and does not need a separate database server for every tool.

Approach

  • I put the whole infrastructure into one Docker Compose project, so one command starts everything.
  • I chose existing tools for the common jobs and wrote my own code only where nothing fit.
  • I kept my own applications out of this repository. They are cloned into sibling folders and mounted, so each one can be deployed on its own.
  • I wrote a small TypeScript helper package and two custom Dashy widgets for the gaps between the tools.
  • I added AI in three places only, where it saves real work.

Architecture and design decisions

  • The stack runs Paperless-ngx with Gotenberg and Tika for document conversion, n8n for automation, Firefly III with its data importer for finance, Mealie for recipes, Grocy for household stock and Dashy as the start page.
  • One PostgreSQL 18 instance with pgvector serves all services. A setup script creates one database and one owner role per service on a fresh volume, so the services are separated by SQL and not by extra servers.
  • Redis works as cache and queue for n8n and Paperless.
  • The custom NestJS API, the react-admin dashboard and the nginx and autossh container are cloned next to this repository and mounted in.
  • The helper package is mounted into n8n as the myhelpers module. The Dashy widgets read the API key from a build time variable and not from the code.
  • Scans arrive in a mounted scan folder that Paperless reads. Backups go to a separate backup folder.
  • AI appears in three places. paperless-ai asks a model for the title, tags and sender of every new document. Mealie uses model credentials from the .env file for recipe import. The n8n workflows call Anthropic and OpenAI with credentials that stay inside n8n.

Reliability and performance

  • Runtime data and secrets stay out of version control.
  • Each service has its own database and owner role, so a mistake in one tool cannot touch the data of another.
  • The n8n credentials never leave the n8n store.
  • Backups are handled in a separate repository, home-backup.

Outcomes

  • One docker compose up starts about a dozen services that share storage.
  • A scan lands in the document archive without any manual step.
  • Documents get a title, tags and sender automatically.
  • The custom applications can be updated one at a time without touching the rest.
  • The repository is public and MIT licensed.

Known gaps

  • I have no uptime numbers or measurements for speed and memory use.
  • I have not tested the stack on more than one machine.
  • I do not say how well the automatic tagging works. I have no error rate for it.
  • The home dashboard in this setup is private, so only the API and the setup are public.
  • I do not claim this setup is hardened for a shared or public network. Public access goes through a separate reverse proxy page.

Get in touch

Hiring for architecture, technical leadership or applied AI engineering?

I answer questions about any of the case studies in detail, including the parts the source material does not cover.