Miabi

The open-source, self-hosted PaaS for shipping apps, not infrastructure.
Docker Compose isn't enough. Kubernetes is overkill. Miabi is the middle.
Multi-tenancy · GitOps · rolling & canary · built-in registry · analytics · monitoring · multi-node.

Live Demo · Quick Start · Features · Comparison · Architecture · CLI · Docs

Table of Contents

• Overview
• Live Demo
• Why Miabi
• Core Features
• Feature Comparison
• Architecture
• Requirements
• Quick Start
• API Documentation
• Screenshots
• Ecosystem
• Documentation
• Contributing
• License

Overview

Miabi is a self-hosted, developer-first Platform-as-a-Service for containerized apps. Push an app — from a Git repo, a Docker image, or a marketplace template — and Miabi handles the rest: build, deploy, domains, automatic SSL, databases, scaling, backups, monitoring, and analytics. All from one web interface, in minutes, without touching a single Docker command.

It is designed as a fully self-hostable alternative to platforms like Heroku, Render, and Railway — giving you complete ownership of your infrastructure, data, and runtime, on a VPS, dedicated box, homelab, or cloud VM.

The name. Miabi is Tshiluba (Kasai, DR Congo 🇨🇩) for the muabi trees — traditionally associated with blessing and growth. It joins the same family as its sibling projects Goma Gateway and Posta.

Why Miabi

Miabi is built for developers, teams, hosting providers, and organizations that want the simplicity of a modern Platform-as-a-Service without giving up control of their infrastructure.

Whether you're deploying a single application on a VPS, running a shared hosting platform for hundreds of customers, or building an internal developer platform, Miabi provides everything you need in one integrated platform.

The gap Miabi fills

Docker Compose isn't enough for production — no rolling updates, no rollback, no TLS, no multi-tenancy. Kubernetes is overkill — a service mesh just for canary, Argo CD or Flux just for GitOps, and a platform team to keep it all running. Miabi sits in the middle: production-ready deployments on plain Docker, with the strategies you actually need built in.

Developer-first experience

• Deploy applications from Git repositories, Docker images, or Marketplace templates
• No Kubernetes knowledge required
• Modern web interface, REST API, and official CLI
• Buildpacks for projects without Dockerfiles
• One-click deployments, rollbacks, and zero-downtime updates

Built for multi-tenancy

Unlike most self-hosted PaaS platforms, Miabi was designed around workspaces from day one.

Every application, database, domain, volume, registry image, secret, backup, and deployment belongs to a workspace, making Miabi ideal for:

• Shared hosting providers
• Agencies managing client applications
• SaaS platforms
• Internal developer platforms
• Universities and organizations

Docker without Kubernetes complexity

Miabi delivers a cloud platform experience while staying Docker-first.

• Single-node and multi-node deployments
• Optional Docker Swarm clustering
• Rolling (zero-downtime) and canary deployments — no service mesh required
• Built-in load balancing
• Docker import for existing applications
• No Kubernetes cluster to operate

Production-ready networking

Powered by Goma Gateway, Miabi includes:

• Automatic HTTPS with Let's Encrypt and wildcard certificates
• DNS provider integrations
• Built-in load balancing and canary traffic splitting
• Gateway middlewares
• Custom domains with workspace-aware routing

Secure by design

Security is built into the platform — not added later.

• Workspace isolation
• Role-based access control (RBAC)
• Encrypted secrets and audit logs
• Two-factor authentication
• OAuth / OpenID Connect
• Enterprise SAML, LDAP, and Active Directory support

Automate everything

Miabi is API-first. Everything available in the web interface is also available through:

• REST API with OpenAPI documentation
• Official CLI
• GitOps and CI/CD pipelines
• Terraform / OpenTofu provider

Own your platform

Run Miabi on a VPS, dedicated server, bare metal, homelab, or private/public cloud. No vendor lock-in. No managed control plane. Your infrastructure, your data, your rules.

Core Features

Applications & deployments

• Deploy from a Git repo (build), a Docker image (pull), or a marketplace template
• Buildpack builds (no Dockerfile required) with configurable memory/time limits
• Releases with one-click rollback and full deployment history
• Zero-downtime updates with canary aliases and weighted traffic splitting
• Env vars, a workspace secret vault, and per-app resource limits
• Jobs — run one-off commands in an app's runtime context
• Stacks — group related apps (compose-style); Environments — dev → staging → prod
• Per-app timeline of lifecycle events
• Built-in container registry — push & pull your own images with docker login <registry> -u <workspace-name> -p <api-token> (or your username); multi-tenant and namespaced per workspace, with local or S3/MinIO storage and an optional garbage-collector

Domains, networking & TLS

• Domains with DNS-verified ownership
• Routing via Goma Gateway (pluggable proxy) with workspace-owned middlewares
• Automatic TLS — default HTTP-01 ACME (Let's Encrypt), managed wildcard / DNS-01 certs via a connected DNS provider (auto-renewed), and uploaded custom certs (encrypted)
• Workspace-isolated Docker networks carved from a managed address pool (so a busy multi-tenant host never exhausts Docker's small default pool), a configurable roomy CIDR for the shared proxy network, per-node edge gateways, and on-demand port forwarding to managed databases

Data, storage & backups

• Databases — provision PostgreSQL, MySQL, MariaDB, Redis, libSQL, and MongoDB with managed credentials and in-place version upgrades
• Volumes — persistent Docker volumes owned by workspaces: node-local by default, or shared (RWX) storage a replicated cluster app can mount across nodes — NFS, CIFS/SMB, or a host-path bind to operator-managed storage under /mnt/* (a NAS mounted on every node; privileged workspaces)
• Backups — scheduled + manual database backup/restore and volume archives, to local, MinIO, or S3

Multi-node & clustering

• Nodes — add remote Docker hosts; the node agent dials the control plane over an outbound WebSocket tunnel (NAT/firewall friendly)
• Cluster mode — optional, auto-detected Docker Swarm with encrypted overlay networks
• Replicated service apps — when cluster mode is on, apps deploy as replicated Swarm services by default (opt out per app); stateful apps with node-local storage stay pinned to a container automatically
• Cluster ingress — public traffic reaches a clustered app's tasks wherever the scheduler placed them, through the central gateway on a shared ingress overlay that survives gateway restarts; the app detail shows the real nodes replicas run on
• Image distribution — built images are pushed to the internal registry so any node can pull them (credentials are distributed to worker tasks), making multi-node deploys and rollbacks of Git-built apps work across the cluster
• Housekeeping — reconcile drift and reclaim disk; Docker import — adopt pre-existing containers/volumes/networks

CI/CD & GitOps

• Pipelines — pipeline-as-code CI/CD
• Build runners — dedicated build/pipeline machines that keep build load off app-hosting nodes; a co-located built-in runner ships for single-node/homelab, and an optional "builds require a runner" guarantee keeps builds off production nodes entirely
• GitOps — declarative, pull-based reconciliation from miabi.io/v1 manifests, plus an imperative one-shot apply (with dry-run, diff & prune) — no separate controller to run (no Argo CD or Flux)
• Git push deploy, stored Git + container-registry credentials, signed webhooks, and notifications
• Automation — everything is REST + OpenAPI, plus a CLI and an official Terraform / OpenTofu provider

Identity, teams & access

• Auth — registration, login with email or username, password reset, JWT sessions with Redis-backed revocation, API tokens, and 2FA (TOTP)
• SSO & directory — OAuth 2.0 / OpenID Connect (GitHub, Google, generic OIDC); Enterprise adds SAML 2.0, SCIM provisioning, and LDAP / Active Directory sign-in (users log in with their directory credentials on the normal login form) with directory groups mapped onto platform-admin and per-workspace roles
• Workspaces & teams — members, invitations, and organizations; each workspace has a unique name handle (its URL and docker login namespace) plus a free-text display name, and each user a unique username
• RBAC — built-in roles Owner · Admin · Developer · Viewer, enforced in middleware and by workspace_id scoping; Enterprise adds custom roles (named permission sets) and per-resource policies (grant a role on a single app/domain/database)
• Container security profiles — optional non-root ("restricted") profile runs app and job containers as a platform UID with no-new-privileges; outbound webhooks are SSRF-guarded
• Plans & quotas, per-workspace encryption keys (keyring/DEK), key rotation, and crypto-shred on delete

Marketplace

Official, versioned templates: WordPress, Ghost, Nextcloud, n8n, Gitea, Forgejo, Umami, NGINX, pgAdmin, phpMyAdmin, mongo-express, libSQL, Posta, PostgreSQL, MySQL, Redis, and MongoDB.

Monitoring & operations

• Container CPU/memory/disk metrics and workspace health with retained history
• Prometheus integration and health endpoints
• Log storage — deployment, pipeline, job, and backup logs are externalized from Postgres to a shared filesystem store with a bounded DB tail, retention, size caps, and full-log download (live tailing unchanged)
• Append-only audit log of every mutating action, with optional SIEM streaming to an external pipeline (syslog / webhook, Enterprise)
• Admin platform — nodes/cluster, users, plans, settings, OAuth providers, SSO (SAML / LDAP / Active Directory), license, and SIEM

Analytics

Every app gets HTTP traffic, performance, and privacy-first web analytics in the console — with zero instrumentation. Because every request already flows through Goma Gateway, there is no JS snippet, no SDK, and no code change to your app.

• Traffic — requests/sec, status mix (2xx–5xx), bandwidth in/out, and your busiest routes
• Performance — p50 / p95 / p99 latency, gateway-vs-upstream split ("is my app slow or the gateway?"), error rate, and Apdex
• Web analytics — unique visitors, top pages, referrers, countries, and device/browser families
• Privacy-first — cookieless, no consent banner, IPs never stored; unique visitors via HyperLogLog sketches, not per-person rows — first-party and GDPR-lean

Architecture

Browser / CLI / API clients
        │
        ▼
Goma Gateway (routing, TLS/ACME) ─▶ Miabi (Go/Okapi) ─▶ Docker Engine (local + remote via agent)
                                          │  serves API + web UI (single binary)
                                          │  └─ asynq worker (deploys, provisioning, backups)
                                          └─ PostgreSQL (GORM) · Redis (cache/queue)

The web console source lives in web/ and is embedded into the Go binary, so a deployment is a single image. The node agent is a separate module, github.com/miabi-io/agent — a thin Docker proxy that needs only an outbound connection and the local Docker socket.

Requirements

• Go 1.25+ (to build)
• PostgreSQL
• Redis
• A reachable Docker socket

Quick Start

curl -fsSL https://get.miabi.io | sudo MIABI_DOMAIN=miabi.example.com \
  MIABI_ADMIN_EMAIL=you@example.com bash

Installs Docker if missing, brings up the stack, and prints the admin password. Then:

miabi-stack status
miabi-stack restart
miabi-stack update
miabi-stack uninstall

Without the script

The Miabi image is the installer — there is no binary to install:

docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc/miabi:/etc/miabi \
  miabi/miabi:1.4.0 install --domain miabi.example.com --admin-email you@example.com

install, update, restart, status and uninstall are the same command with a different verb.

Installation docs — options, the /etc/miabi/stack.yaml manifest, the built-in registry, custom gateway config, and running Miabi under Docker Compose instead.

Docker Compose

Prefer to drive Compose yourself? examples/compose/ brings up the same stack — see the installation docs.

Local development

git clone https://github.com/miabi-io/miabi.git
cd miabi

make run        # API server on :9000 (worker embedded)
make worker     # standalone background worker (optional)
make build-ui   # build the Vue console into the embedded assets
make test       # unit + integration tests

API Documentation

• OpenAPI spec and interactive docs at /docs and /openapi.json on your instance
• The spec is generated from code annotations — see internal/routes/

Live Demo

Try Miabi without installing anything — at https://demo.miabi.io.

The demo is seeded with two independent customers across three workspaces, so you can see Miabi's core ideas first-hand: shared hosting on Docker with true workspace isolation and role-based access — every app, database, domain, volume, and secret belongs to a workspace, one tenant can never see or reach another's resources, and a member only sees the workspaces and permissions their role grants.

Sign in as any of these (password: MiabiDemo2026):

Switch workspaces from the workspace picker to watch the entire console re-scope; sign in as the other customer to confirm the isolation boundary, or as dev@acme.demo.miabi.io to see a single-workspace, Developer-scoped view.

[!IMPORTANT] These are workspace accounts, not the platform admin. They can't see the admin platform (nodes/cluster, users, plans, settings, licensing). To explore the platform-admin features, install Miabi on your own server or local Docker — the first account you seed is the platform admin.

[!NOTE] Apps on the demo run under a restricted (non-root) security profile: each container runs as a dedicated, unprivileged user, not root. If you deploy a new app, make sure its image can run as a non-root user — for security, every new app on the demo is restricted from running as root, so images that require root will fail to start.

Screenshots

Miabi's web console manages every resource — deployments, domains, databases, backups, monitoring, marketplace, teams, and the admin platform.

Workspace dashboard	Deploy an application
Login screen	Application overview & deployments
Canary deployment	GitOps deployment
CI/CD pipelines	Marketplace
Domains, routes & TLS	Managed databases
Backups	Monitoring
Analytics overview	Analytics http traffic
Nodes & cluster	Platform admin

Feature Comparison

Ecosystem

Miabi is part of a family of self-hosting tools by the same author:

• Okapi — the Go web framework Miabi is built on
• Goma Gateway — reverse proxy + TLS/ACME
• miabi-cli — the official CLI
• terraform-provider-miabi — official Terraform / OpenTofu provider for managing Miabi resources as code
• agent — the outbound node agent for multi-node deployments
• runner — dedicated build/pipeline runner
• marketplace — official app templates catalog
• Posta — self-hosted email delivery & inbound platform
• pg-bkup / mysql-bkup — database backup tools

Documentation

• API docs — /docs and /openapi.json on a running instance

Contributing

Contributions are welcome. Please open an issue before submitting a pull request.

Contact

• Email: maintainers@miabi.io

License

Miabi core is free and open source under the GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later) — see LICENSE and NOTICE. A commercial license is available for uses that don't fit the AGPL (e.g. offering a modified Miabi as a hosted service without publishing your changes).

Enterprise features (everything under internal/enterprise/, built with the enterprise tag) are not AGPL: they are licensed under the Miabi Enterprise License — see internal/enterprise/LICENSE.md — and require a valid commercial license to use. See LICENSING.md for the full breakdown, and CONTRIBUTING.md for the contributor terms.

Copyright

Copyright (c) 2026 Jonas Kaninda