Tada Cloud — My Personal Cloud That Doesn't Need a Beefy Server

🧠 Overview

I wanted my own cloud. Not the "pay $50/month for someone else's computer" kind — the "I run everything myself on one machine" kind. The problem? Every self-hosted app wants its own PostgreSQL, its own Redis, its own web server. Spin up a dozen apps and suddenly you need 16 GB of RAM just for infrastructure overhead.

The closest thing that exists is Cloudron — a self-hosted platform that shares infrastructure across apps. Same idea: one database, one proxy, one place to manage everything. I loved the concept, but Cloudron doesn't have real SSO (no OIDC/OAuth2 provider — each app manages its own users), and it's a closed-source appliance with its own runtime, not infrastructure-as-code. I wanted something I could version-control, customize, and actually understand top to bottom. So I built my own.

Tada Cloud is that. All apps share the same databases, the same cache, the same proxy, and the same login system — but everything is plain Docker Compose files you can read, fork, and modify. The result: 12+ production apps running on ~8 infrastructure containers, all behind automatic HTTPS on my domain v4.io.vn. One docker compose up -d and the whole thing comes alive.

🎯 5W1H Analysis

Who

It's me — tada (Vuong). I built this for myself, and now it's also powering infrastructure for a friend's startup team on a budget. If you're a self-hoster or a small team running on a single cheap VPS where every megabyte of RAM matters, this might resonate with you too.

Oh, and the domain? v4.io.vn — that's v[uong] = v4. Yes, I turned my name into a domain hack. No regrets.

What

Tada Cloud is my entire personal cloud infrastructure, defined as code. Everything lives in Docker Compose files, env configs, and init scripts. It provides:

Shared PostgreSQL, MySQL, and Valkey (Redis-compatible) instances — no duplicate databases per app
An Nginx reverse proxy that auto-discovers new apps from the Docker socket
Automatic Let's Encrypt SSL for every service — just set two env vars and you're HTTPS
Centralized SSO via Zitadel — one login for everything
A custom Rust logout service I built because nobody else solved cross-app logout properly
12 self-hosted apps and counting

When

Started as a weekend project. It... didn't stay a weekend project. It's now running 24/7 in production, and it's grown beyond just my personal use — I'm currently using it to support a friend's startup team. The v4.io.vn instance is my test/dev environment, pointing straight at my home router (please don't hack me), where I experiment and break things freely. The production environment runs on a cheap VPS behind a Cloudflare Tunnel with its own domain, where I've added more team-centric tools like Headscale (for secure VPS access via WireGuard), Appwrite (backend-as-a-service for the devs), Plane (project management), and more.

I keep adding apps whenever someone on the team needs something — or whenever I find something cool and think "that would take 15 minutes to deploy."

Where

Everything runs on a Linux server (Fedora) with an AMD GPU (ROCm) for ML inference, video transcoding, and PDF rendering. All services are containerized with Docker and served over HTTPS at v4.io.vn (with tada.io.vn as an alias for the auth service, because why have one domain when you can have two).

Why

Here's the math that motivated this project:

A typical self-hosted app runs its own PostgreSQL (~~200–500 MB), its own Redis (~~50–100 MB), and its own web server. Multiply that by 12 apps and you're looking at 3–7 GB of RAM just for infrastructure duplication. That's absurd for a personal server.

Tada Cloud flips the model:

Share databases and caches across all apps — one PostgreSQL, one Valkey, done
One command (docker compose up -d) brings everything online
One login (Zitadel SSO) for all apps — no more password fatigue
Zero-touch SSL — every new app gets HTTPS automatically
One line to add an app, one line to remove it

How

The flow is surprisingly simple:

Infrastructure boots first — PostgreSQL, Valkey, Nginx proxy, Zitadel, and the logout service start up and create dedicated Docker networks
Apps plug into shared networks — each app's compose file declares which infrastructure it needs (e.g., infra-postgres, infra-valkey) and talks to services by container name
Nginx auto-discovers apps — drop a container with VIRTUAL_HOST=myapp.v4.io.vn and Nginx picks it up automatically. No config files to edit.
ACME companion handles SSL — sees LETSENCRYPT_HOST, gets a certificate, renews it forever. I literally never think about certs.
Zitadel provides SSO — Homarr, Forgejo, Nextcloud, Immich all authenticate through one identity provider
Logout service cleans up — my custom Rust service makes sure "log out" actually means "log out everywhere", not just "log out of the identity provider while staying logged into 11 other apps"
Forgejo Actions deploys the stack — pushing to the repo triggers a CI pipeline that SSHs into the server and runs docker compose pull && docker compose up -d

🏗️ Architecture / Design

The Big Picture

                          ┌─────────────────────────────────────┐
                          │         Internet (that's you!)      │
                          └──────────────┬──────────────────────┘
                                         │ :443
                          ┏━━━━━━━━━━━━━━▼━━━━━━━━━━━━━━━━━━━━━━┓
                          ┃           Home Router               ┃
                          ┃   (Configured with Dynamic DNS)     ┃
                          ┗━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┛
                                         ┃
                          ┌──────────────▼──────────────────────┐
                          │    nginx-proxy + acme-companion     │
                          │ (auto-discovery, SSL termination,   │
                          │   HTTP/3, gzip, reverse proxy)      │
                          └──────┬───────┬───────┬──────────────┘
                                 │       │       │
           ┌─────────────────────┘       │       └─────────────────────┐
           ▼                             ▼                             ▼
  ┌─────────────────┐          ┌──────────────────┐          ┌──────────────────┐
  │   Applications  │          │   Auth Services  │          │  Logout Service  │
  │   (12+ apps)    │          │   (Zitadel SSO)  │          │  (Rust, Valkey)  │
  └─┬──────┬──────┬─┘          └─┬──────────────┬─┘          └───────┬──────────┘
    │      │      │              │              │                    │
    │      │      │              │              │                    │
    │      │      └──────────────┼────────┐     │     ┌──────────────┘
    │      └────────────┐        │        │     │     │
    ▼                   ▼        ▼        ▼     ▼     ▼
┌───────┐          ┌──────────────┐    ┌────────────────┐
│ MySQL │          │  PostgreSQL  │    │     Valkey     │
│       │          │ (+ pgvector) │    │ (Shared Inst.) │
└───────┘          └──────────────┘    └────────────────┘

Network Isolation (a.k.a. "Apps Can't Snoop on Each Other")

Each infrastructure service gets its own Docker network:

Network	Purpose	Used By
`infra-nginx-proxy`	HTTP routing & SSL	All apps
`infra-postgres-*`	PostgreSQL access	Zitadel, Homarr, Immich, Forgejo, Nextcloud, Spliit
`infra-mysql-*`	MySQL access	Invoice Ninja
`infra-valkey-*`	Cache & session access	Homarr, Immich, Forgejo, Nextcloud, Invoice Ninja, Logout Service
`infra-zitadel`	OIDC/OAuth2 auth	Homarr, Forgejo

Apps only get access to what they actually need. IT-Tools is a static site? It gets infra-nginx-proxy and nothing else. Nextcloud needs the full stack? Four networks. No app can accidentally (or maliciously) talk to a database it has no business touching.

Directory Structure

tada-cloud/
├── docker-compose.yml              # Main orchestrator (include directives)
├── compose/
│   ├── infrastructure/
│   │   ├── db/                     # PostgreSQL, MySQL
│   │   ├── cache/                  # Valkey 9
│   │   ├── proxy/                  # nginx-proxy, acme-companion, logout-service
│   │   └── auth/                   # Zitadel
│   └── apps/
│       ├── _template/              # Template for new apps
│       ├── homarr/                 # Dashboard
│       ├── immich/                 # Photo management
│       ├── forgejo/                # Git hosting
│       ├── nextcloud/              # File sync & office
│       ├── invoiceninja/           # Invoicing
│       └── ...                     # 7 more apps
├── config/                         # Runtime configuration files
├── envs/                           # Environment variable files (secrets)
├── init-db/                        # Database initialization scripts
└── data/                           # Persistent volumes

The "One File to Rule Them All" Pattern

The root docker-compose.yml is hilariously simple — it's just a list of include directives:

include:
  # Infrastructure
  - compose/infrastructure/db/postgres/docker-compose.yml
  - compose/infrastructure/cache/valkey/docker-compose.yml
  - compose/infrastructure/proxy/nginx-proxy/docker-compose.yml
  - compose/infrastructure/auth/zitadel/docker-compose.yml

  # Applications
  - compose/apps/homarr/docker-compose.yml
  - compose/apps/immich/docker-compose.yml
  - compose/apps/forgejo/docker-compose.yml
  # ... more apps

Want to add a new app? Write a compose file, add one line here. Want to remove one? Delete the line. That's it. No Kubernetes, no Helm charts, no YAML nightmares (okay, it's still YAML, but manageable YAML).

⚙️ Tech Stack

Layer	Technology	Why (the honest reason)
Orchestration	Docker Compose (with `include`)	Simple, declarative, and I don't need Kubernetes for 12 apps
Reverse Proxy	nginx-proxy + acme-companion	Auto-discovers containers, handles SSL — I never touch Nginx configs
Database	PostgreSQL (with pgvector)	Battle-tested, and pgvector means Immich can do vector search natively
Database	MySQL	Because Invoice Ninja insists on it (you can't win them all)
Cache	Valkey (Redis fork)	Linux Foundation-maintained Redis fork — same API, no licensing drama
Authentication	Zitadel	Full OIDC/OAuth2/SAML, self-hosted, and the admin UI is actually good
Logout Service	Custom Rust binary	Built it myself because nobody else solved cross-app logout
SSL	Let's Encrypt (ACME)	Free, automated, and I literally forget it exists (which is the point)
GPU	AMD ROCm	ML inference, video transcoding, PDF rendering — one GPU, many apps
Protocols	HTTP/3 (QUIC), TLS 1.3	Because why serve a modern cloud over legacy protocols?

✨ Key Features

Shared Infrastructure — The Whole Point

Instead of 12 PostgreSQL containers eating your RAM alive:

One shared PostgreSQL for all apps — saves ~200–500 MB RAM per app
One Valkey cache instead of a Redis per app — saves another ~50–100 MB each
One Nginx proxy that auto-discovers everything — no config files, no reload commands

Do the math: 12 apps x ~300 MB saved = ~3.6 GB of RAM I'm not wasting. That's a whole extra server's worth of headroom.

🔐 Coordinated Cross-App Logout — The Feature I Had to Build Myself

This is the one I'm most proud of (and most annoyed that I had to build).

Here's the problem: you set up SSO with Zitadel, everything's great, users log in once and access all apps. Beautiful. Then they click "logout" and... they're only logged out of Zitadel. Every app still has its own session cookie in Valkey. The user thinks they're logged out. They're not. That's a security nightmare.

No existing solution handled this properly, so I wrote a Rust logout service that:

Intercepts logout requests at auth.v4.io.vn/logout
Reads a domain-to-service mapping (domains.yaml) to know which apps are active
Nukes the user's sessions in Valkey across every single registered app
Fires per-app cleanup routines (cleanup.yaml) for apps with special logout needs

When you log out, you're actually logged out. Everywhere. For real.

🌐 HTTP/3 (QUIC) — Because It's Not 2015 Anymore

Most self-hosted platforms still serve everything over HTTP/2-on-TCP. Tada Cloud runs HTTP/3 (QUIC) by default across all apps. Why does this matter?

0-RTT connection resumption — returning visitors skip the TLS handshake entirely. Pages just... load.
Connection migration — switching from Wi-Fi to mobile data mid-upload? The connection survives. This is a game-changer for uploading photos to Immich from my phone or syncing large files to Nextcloud.
No head-of-line blocking — unlike HTTP/2, a single dropped packet doesn't freeze all your parallel requests
Mozilla-Modern TLS policy — TLS 1.3 only, no legacy cipher suites, no compromises

🔑 Single Sign-On (SSO) — My Own Google Account, But I Own It

Think about how Google works: you sign into your Google account once, and you're instantly logged into Gmail, Drive, YouTube, Calendar — everything. You don't create separate accounts for each service. And when you log out, you log out of all of them.

That's exactly what Tada Cloud does, but self-hosted and under my control.

Zitadel acts as the central identity provider (like Google's account system), and every app connects to it via OIDC/OAuth2. Here's what that means in practice:

Register once — create one account on Zitadel, and you exist across every app. No "create account" flow per service. New team member? One account, instant access to everything.
Login once — sign in at auth.v4.io.vn and you're authenticated across Homarr, Forgejo, Nextcloud, Immich — all of them. No more remembering 12 different passwords. No more "which email did I use for this one?"
Logout everywhere — click logout and the custom Rust service nukes your sessions across every single app (the part Google does well but most SSO setups completely botch — see the section above).
Role management — Zitadel's admin panel lets me manage who can access what. Need to give a developer access to Forgejo and Plane but not Immich? Done. Need to revoke someone's access to everything? One click. It's the same kind of centralized user management you'd expect from Google Workspace or Okta — except it runs on my server and costs $0/month.

The difference from Google? I own the data, I own the infrastructure, and there's no vendor lock-in. If Zitadel disappears tomorrow, I swap in another OIDC provider. Try doing that with Google.

GPU Acceleration — One GPU, Many Jobs

AMD ROCm lets Immich run AI photo recognition, Stirling-PDF render documents, and ConvertX transcode files — all on the same GPU
Since these workloads are bursty and rarely overlap, sharing works great in practice

Modular Add/Remove — It's Almost Too Easy

There's an app template (compose/apps/_template/) so I don't start from scratch
Adding an app = write a compose file + add one include line
Removing an app = delete the include line
Total time to add a new app: usually under 15 minutes

🚀 Implementation Details

Database Initialization — No Manual SQL Sessions

Rather than SSH-ing in and running CREATE DATABASE by hand every time, apps use SQL init scripts in init-db/apps/<app-name>/:

docker exec -i postgres psql -U postgres < init-db/apps/my-app/init.sql

Secrets Stay in Their Lane

Secrets are strictly separated from config, and the directory structure mirrors the compose layout:

envs/
├── infrastructure/db/postgres/.env       # DB root password
├── infrastructure/cache/valkey/.env      # Cache password
├── infrastructure/auth/zitadel/.env      # OIDC secrets
└── apps/immich/.env                      # App-specific secrets

Each compose file loads only the env files it needs. Immich can't read Forgejo's secrets. Forgejo can't read Nextcloud's. Simple, effective.

Nginx Tuning for "I Upload 4K Videos From My Phone"

The default Nginx config would choke on the kind of media I throw at Immich and Nextcloud. So:

CLIENT_MAX_BODY_SIZE=0 — no upload size limit (yes, zero means unlimited)
600-second timeouts — large video uploads don't get killed mid-transfer
Massive proxy buffers (128 x 256KB) — streaming responses without stuttering
Gzip compression, file caching, TCP optimizations — the usual performance wins
JSON logging — because grep-ing through access logs is for the birds

📚 Lessons Learned

Sharing infrastructure is the move. Seriously. The RAM savings alone justify the entire project. One docker compose up -d and I have a full cloud. It's beautiful.
Docker Compose include is criminally underrated. Everyone talks about Kubernetes. Nobody talks about the fact that Compose include gives you modularity, composability, and simplicity in one package. For personal-scale hosting, it's the right tool.
SSO is worth the pain of setup. Configuring OIDC for each app is tedious. But once it's done? One login for everything. I'd do it again in a heartbeat.
Logout is 10x harder than login. I genuinely did not expect to have to build a custom Rust service just to make "log out" work properly. But here we are. SSO providers solve login; they punt on logout. Now I know why.
Network isolation is free security. Per-service Docker networks mean an app compromise doesn't automatically give access to all databases. It costs nothing to set up and could save everything.
One GPU, many apps, zero problems. Bursty ML workloads + bursty rendering workloads = almost no contention in practice. Sharing works.

🔮 What's Next

In Progress

docker-mailserver — self-hosted email for the startup team. Because relying on Gmail feels wrong when you're already self-hosting everything else. Currently wrestling with DKIM/DMARC/SPF setup.
Fail2ban — intrusion prevention. The v4.io.vn instance points at my home router (remember?), so auto-banning IPs that brute-force SSH or spam login pages isn't optional — it's survival.
oauth2-proxy — authentication reverse proxy that sits in front of apps and enforces Zitadel SSO login before a single byte reaches them.

TODO

Automated backups — scheduled PostgreSQL and Valkey dumps with offsite replication. Currently I back up manually, which is another way of saying "sometimes"
Monitoring stack — Prometheus + Grafana so I can stare at dashboards instead of just hoping everything's fine
Health dashboard — wire up all the health checks into Homarr so I can see at a glance what's up and what's not