Simon Hoiberg's self-hosted SaaS stack: an ownership-first founder setup

Simon Hoiberg shared a self-hosted SaaS stack that is less about chasing novelty and more about owning the important layers: compute, data, queues, automation, observability, AI runtime, source control, content, and object storage.

That fits the broader pattern behind his product portfolio. Simon is connected to products such as FeedHive, Aidbase, LinkDrip, and SignupGate, so the stack is not theoretical infrastructure cosplay. It is the kind of setup a founder reaches for after SaaS margins, platform risk, and operational control start to matter.

The useful framing is simple: use hosted abstractions when they help you move faster, but know which parts of the system you eventually want to own. Simon's stack puts ownership first, then layers automation and AI on top.

The center of gravity is self-hosting. Instead of pushing every concern into a separate managed service, the stack pulls core infrastructure back into systems that can run on servers Simon controls.

That does not mean avoiding every API or hosted service. His AI layer still leaves room for frontier APIs, and products like FeedHive still need platform integrations. The difference is that the durable product state, internal workflows, model experiments, logs, queues, and storage are not automatically spread across a dozen SaaS vendors.

This matters because self-hosting is not only a cost decision. It is a leverage decision. If the infrastructure is portable, documented, and built from open-source parts, the founder has more options when usage grows, pricing changes, or a platform becomes less friendly.

The core infrastructure layer is Hetzner, Kubernetes, Docker, and Node.js. Hetzner is the hosting base, while Kubernetes and Docker provide the deployment and orchestration layer for containerized services. Node.js remains the application runtime for the product code.

This is a very different posture from a purely serverless startup stack. It asks the founder to understand servers, networking, container images, cluster operations, deployments, and recovery. In return, it can offer predictable compute economics and fewer surprises at scale.

The open-source pieces here are important. Kubernetes, Docker components, and Node.js are not locked to one cloud. If the workloads are packaged well, the stack has a realistic path to move between providers or run on different hardware.

The data layer is where the ownership theme becomes clearest: Postgres for primary relational data, pgvector for vector search and embeddings, Redis for fast cache and ephemeral state, and RabbitMQ for durable queues.

Postgres is the boring, durable center. pgvector keeps AI retrieval and embedding similarity search inside the database ecosystem instead of immediately reaching for a separate vector database. That is a practical self-hosting move because product data, agent memory, and retrieval primitives can stay closer together.

Redis and RabbitMQ split two common operational concerns cleanly. Redis is excellent for speed-sensitive cache and lightweight coordination. RabbitMQ is a mature message broker for background work, fan-out, retries, and decoupling services. Together, they replace a set of managed cache and queue services with infrastructure the team can run directly.

The agent ops layer combines OpenClaw, n8n, cron, and webhooks. This is the automation surface: agents, scheduled jobs, repeatable workflows, product scripts, and event-driven glue.

OpenClaw is interesting because it points at a local-first, agentic operating model rather than only chat-based AI. n8n is a strong open-source workflow automation choice for connecting services, APIs, and internal tasks. Cron and webhooks are the simple primitives that keep the system moving without needing a heavy platform for every automation.

For founders, this layer can turn repeated manual work into operating leverage. Content workflows, support workflows, billing checks, data syncs, alerts, and internal admin tasks become explicit workflows instead of browser-tab rituals.

The observability layer is Grafana, Prometheus, logs, and Telegram alerts. Grafana gives dashboards and exploration, Prometheus handles metrics collection and alerting primitives, logs preserve execution context, and Telegram becomes the founder-facing notification channel.

The philosophy is not more dashboards. It is fewer dashboards with better signals. A founder running a self-hosted stack does not want to babysit infrastructure all day; they want enough visibility to know when something is wrong and enough context to act quickly.

Grafana and Prometheus are both major open-source infrastructure tools, which keeps the monitoring layer aligned with the rest of the stack. The alert target can change later, but the metrics and dashboard model remains portable.

The AI compute layer combines Qwen, Vast AI, GPU boxes, vLLM, and still leaves room for frontier APIs. This is a pragmatic hybrid approach: use open-weight models and self-controlled inference where it makes sense, but do not pretend every serious AI task should already be local.

Qwen gives an open model family to experiment with. vLLM provides a high-throughput inference server for running large language models. Vast AI and dedicated GPU boxes create a path to rentable or owned GPU capacity without treating a single frontier API provider as the whole AI strategy.

For a SaaS founder, the advantage is learning curve and optionality. Even if frontier APIs remain the best default for many customer-facing tasks, building experience with open models, inference servers, and GPU economics reduces strategic dependence over time.

The dev and content layer is Forgejo, Git, Strapi, and MinIO. Forgejo is a self-hosted Git forge, Git remains the version-control base, Strapi handles content management, and MinIO provides S3-compatible object storage.

This is another ownership cluster. Source code, internal content, media, files, and product assets can live in systems the team controls. MinIO is especially useful because it speaks the familiar S3-compatible storage model without requiring the workload to stay on Amazon S3.

Strapi also fits the stack because content often becomes a product dependency: marketing pages, docs, help centers, product education, and internal knowledge. Self-hosting the CMS keeps that layer closer to the rest of the operating system.

A lot of the stack has direct open-source anchors: Kubernetes, Docker, Node.js, Postgres, pgvector, Redis, RabbitMQ, OpenClaw, n8n, Grafana, Prometheus, Qwen, vLLM, Forgejo, Strapi, and MinIO all have public source repositories or open-source distributions.

That does not make the stack free. You still pay for servers, GPUs, backups, developer time, monitoring discipline, security work, and operational attention. Open source changes the control model; it does not remove the need to operate software properly.

The important distinction is that open source gives the founder a way to inspect, self-host, migrate, extend, and reason about the system. That is the opposite of building the entire product on black-box abstractions where pricing and product direction can change without much warning.

Simon's public product portfolio gives useful context for the stack. FeedHive is a social media management product, Aidbase is an AI-powered support platform, LinkDrip is a link engagement and shortening product, and SignupGate protects SaaS signups from unwanted users and fraud patterns.

Those products imply a broad infrastructure surface: scheduling, publishing, analytics, AI support, content, link tracking, fraud checks, background jobs, integrations, customer data, and notifications. A self-hosted stack starts to make more sense when one founder portfolio has that many recurring operational needs.

This is the reason the stack is worth studying as an operating system, not just as a list of tools. The tool choices reflect the work: social automation, AI workflows, data ownership, support automation, observability, content, and cost control.

Not blindly. A brand-new SaaS should usually choose the smallest stack that gets the product in front of customers. Self-hosted Kubernetes, RabbitMQ, Grafana, Prometheus, MinIO, a CMS, and GPU inference can be too much infrastructure before the product has earned it.

The better lesson is sequencing. Start with managed services where speed matters, but document which parts of the stack are strategic. As revenue, usage, data volume, AI costs, or platform risk increase, migrate the right layers toward self-hosted, portable, open-source foundations.

Trackk is useful for this because the stack decision should become a visible project plan. You can track which tools are in use, which setup steps are complete, what costs are attached, and which migration work belongs on the launch or maturity ladder.

Simon Hoiberg's stack is a clear bet on ownership: own the data, own the queues, own the monitoring path, own more of the AI runtime, own the source-control and content layers, and keep the product less exposed to vendor drift.

The tradeoff is operational responsibility. Self-hosting rewards teams that can standardize, automate, monitor, back up, patch, and document their systems. It punishes teams that treat servers as a one-time setup task.

For experienced founders, that tradeoff can be worth it. For early founders, it is a roadmap. The strongest move is not copying the entire stack today; it is understanding which parts of your SaaS you eventually want to own.