$ aoox
ID
self-hosted PaaS · Docker · open source

Deploy apps from Git to your own server.

aoox runs your build, deploy, database, domain, and logs on your own server — one dashboard, no vendor lock-in.

Install on your serverSee features
  • Built on
  • Docker
  • Swarm
  • Traefik
  • Nixpacks
  • PostgreSQL
deploy — aoox
$ git push origin main → deployment#a1b2c3queued→ buildnixpacksok42s→ pushregistryok3s→ startblue/greenhealthy✓ https://app.example.com$
## features

Everything you need to run applications in production.

Built on Docker. No special runtime — if it runs in a container, it runs on aoox.

  • dockerfile
  • nixpacks
  • railpack
  • image
  • cli

Deploy from Git or an image

Connect a GitHub/GitLab repo — Dockerfile, Nixpacks, Railpack (with cache between deploys), or a static site — and a webhook triggers a deploy on every push. Or pull a ready-made image from a registry, with auto-update when its tag changes. No repo? The aoox CLI builds and pushes straight from your machine.

Read docs
  • blue/green
  • healthcheck

Zero-downtime & rollback

A health check decides success or failure. Blue/green swaps without downtime, one-click rollback to the previous image.

Read docs
  • swarm
  • replicas
  • rolling update

Multi-node with Swarm

Turn the host into a manager, join other nodes, run apps as a service with replicas. Rolling updates, automatic rollback, and placement per node or label.

Read docs
  • postgres
  • mysql
  • redis

Managed database

PostgreSQL, MySQL, MariaDB, Redis per project. Reference credentials in env, browse tables and run queries from the dashboard.

Read docs
  • cron
  • s3
  • instance

Backup & restore

Database and app volumes, manual or scheduled, with retention and copies to S3. The panel itself can be backed up and restored too.

Read docs
  • traefik
  • acme

Domain & TLS

Point a domain at your app through Traefik, automatic Let's Encrypt certificates, DNS checks from the dashboard — on the host or a remote server.

Read docs
  • ssh
  • xterm

Web terminal & remote servers

Shell into the host or another server over SSH, right from the browser. Deploy to a remote server without an extra agent.

Read docs
  • metrics
  • alerts

Monitoring & notifications

Realtime logs, host and container CPU/RAM metrics with 1-hour-to-30-day history, notifications to Telegram, Slack, Discord, email.

Read docs

And more

--more
## how it works

From repo to URL in three steps.

No aoox-specific config file in the repo — everything is set from the dashboard.

  1. 01

    Create a project & connect a repo

    One project can hold several apps and databases. Paste the Git URL and the branch to deploy.

    Git repositoryhttps://github.com/acme/shop
    Branchmain
    Container port3000
  2. 02

    Choose how to build

    An existing Dockerfile, auto-detected with Nixpacks, or a static site via nginx. Add env and the container port.

    Build method
    Dockerfile./Dockerfile
    Nixpacksauto-detected
    NODE_ENV=production+2 env
  3. 03

    Deploy & watch

    The build runs on the Docker daemon, the image is pushed to the local registry, and a new container comes up once its health check passes — or as a Swarm service with a rolling update.

    ✓buildok
    ✓pushok
    ✓healthhealthy
    ✓swapblue → green
    Runningshop.example.com
Full guide to creating an applicationThe next push deploys automatically via webhook.
## build

Bring your repo as-is.

Six ways to run an application — straight from a repo or straight from an image. Pick per app, and mix within one project.

Dockerfile

./Dockerfile
FROM node:22-alpineWORKDIR /appCOPY . .RUN npm ci && npm run buildCMD ["node", "server.js"]

Full control. Point at the Dockerfile in your repo, Docker handles the rest.

Production, lean images

Nixpacks

(no Dockerfile)
✓detectednode · npm
→installnpm ci
→buildnpm run build
→startnpm start

The stack is auto-detected from your repo's contents, a Dockerfile is generated for you.

Prototypes, repos without a Dockerfile

Static site

dist/ → nginx
→buildnpm ci && npm run build
→outputdist/
✓servenginx:1.27-alpine :80
→spaindex.html fallback

An optional Node build stage, then nginx serves the output folder. SPA mode for client-side routing.

Vite, Astro, docs sites

Ready-made image

registry → pull
→imageghcr.io/acme/api:latest
→authexternal registry
→checkevery 60 min (configurable)
✓updatedigest changes → deploy

No build: pull an image from Docker Hub, GHCR, or your own registry. Auto-updates when the tag's digest changes.

n8n, Uptime Kuma, internal images

Docker Compose

./docker-compose.yml
services:  web: { build: . }  worker: { build: . }  redis: { image: redis:7 }

Deploy a multi-service stack from an existing compose file.

web + worker + queue

Template

built-in catalog
  • wordpress
  • ghost
  • n8n
  • uptime-kuma
  • minio
  • gitea

Ready-made apps, run as a compose stack in a few clicks.

WordPress, Ghost, n8n, …

Build args for Dockerfile & Nixpacks; env is applied at runtime, so secrets never end up stored in the image.

## team

One instance, many projects.

Instance roles control who can touch infrastructure; per-project membership controls who sees and changes what.

Instance roles
Can doowneradminmember
Projects they create or are added to✓✓✓
See every project✓✓–
Deploy, rollback, backup, jobs✓✓✓
2FA, change password, API tokens✓✓✓
Invite instance members✓✓–
Registry, remote servers, Swarm, notifications✓✓–
Web terminal & bind mounts✓✓–
Audit log✓✓–
Change roles, delete & reset users' passwords✓––
Provision registry & proxy, instance backup✓––
Per-project roles
  1. adminManages project members and can delete the project, plus everything a developer can do.
  2. developerCreates & deploys apps, databases, stacks, domains, backups.
  3. viewerRead-only — sees status, logs, and metrics without being able to change anything.

A member only sees projects they created or were added to; the instance owner and admins see everything.

Inviting members
  1. 1Inviteemail + role
  2. 2Copy linkshown once, 7 days
  3. 3Joinname + password

No email server — an invite link is generated once, you send it yourself via chat.

More on users & roles (docs in Indonesian)
## self-host

Runs on your own server.

Three containers from one compose file. No cloud account, no telemetry — your data and images stay on your server.

  • ✓Docker 24+ & Compose v2the only dependency
  • ✓Linux VPS1 vCPU / 1 GB is enough to start
  • ✓Port 3000 & 3001dashboard & API; 80/443 if you use a domain
Installation guideInstall on your own domain
ssh root@server
$ git clone https://github.com/hideandseeklab/aoox-api.git$ cd aoox-api && cp .env.dist.example .env.dist# fill in POSTGRES_PASSWORD, JWT_SECRET, ENCRYPTION_KEY, DOCKER_GID$ docker compose -f docker-compose.dist.yml --env-file .env.dist up -d→ open http://<server>:3000/setup
webNext.js · :3000
apiNestJS · :3001
postgresaoox data
docker compose · aoox network+ registry, proxy, app, db as needed
## faq

Common questions.

Short answers. The full detail is in the docs.

Still have questions?
Read the docs (Indonesian)Open an issue on GitLab
+How is this different from Coolify or other self-hosted PaaS tools?
The concept is similar: a self-hosted PaaS on top of Docker. aoox focuses on a lean flow — project, application, database — and code that's easy to read (NestJS + Next.js), with no extra agent on the server.
+Do I need Kubernetes?
No. A single host with the Docker Engine is enough. For several machines there are two paths without Kubernetes: connect a server over SSH as a separate deploy target (Remote server), or turn on Docker Swarm and run apps as a service with replicas, rolling updates, and per-node placement.
+Can a repo without a Dockerfile be deployed?
Yes, pick the Nixpacks build method: the stack is auto-detected and a Dockerfile is generated for you. The first build is slower and has no dependency cache — details in the build docs.
+What about application and database data?
Docker volumes for persistent data, bind mounts for host paths, file mounts for config. Databases and volumes can be backed up manually or on a schedule with copies to S3 — and so can the aoox panel itself, so an instance can be restored on a new server — Backup & restore.
+Does it deploy automatically on push?
Yes, via a GitHub/GitLab webhook with an optional secret. Pull requests can also get a preview on their own subdomain, and an app run from an image can update itself when its tag changes — Webhook and PR previews.
+Is there downtime during a deploy?
For applications with a domain and a health check, no: the new container comes up next to the old one (blue/green) and only replaces it once healthy. A failed build never touches the running container.
+Does it work on Windows?
For development, yes (Docker Desktop). For production, use Linux.
+Does data ever leave my server?
No telemetry, no cloud service is contacted, except what you set up yourself: Let's Encrypt for certificates, an S3 destination for backups, and notification channels.
+Is the dashboard available in English?
Not yet — the dashboard, and all documentation, is Indonesian only for now. This landing page is the first English surface; an English UI is on the roadmap, not shipped.
ready in ± 5 minutes

The server is already there. Just deploy.

Clone, fill in env, docker compose up — then open /setup and deploy your first application.

$git clone https://github.com/hideandseeklab/aoox-api.git && cd aoox-api && cp .env.dist.example .env.dist
Installation guideSee the code on GitLab
  • ✓One compose file
  • ✓No telemetry
  • ✓Open source