Skip to content
nocapcloud

Features

Everything you need to ship from your own server.

Every section says what works today and which version brings the rest. Status follows the roadmap.

Works today v0.1 First release Later versions
01 v0.1

Deploy

Bring a Dockerfile or a Docker Compose file. Nocap clones the last commit, builds the image and runs it as a normal container on your server.

  • Dockerfile and Compose. The port comes from the EXPOSE line, so most apps need no settings.
  • One build at a time. A queue in Postgres keeps builds from using all the RAM of a small server.
  • Live logs. Build and runtime logs stream to the panel as they happen.
  • Deploy, restart, stop. One button each, from any device.
meridian-api · build #42 Building

12:04:01 Cloning main at 3f9c2a1

12:04:03 Step 1/6 FROM node:22-alpine

12:04:09 Step 4/6 RUN pnpm install --frozen

12:04:31 Step 6/6 CMD ["node", "dist/index.js"]

12:04:33 Image meridian-api:3f9c2a1 built

12:04:35 Health check passed

12:04:35 Live at https://api.meridian.example

02 v0.1

GitHub and GitLab

Connect an account once, then pick repositories from a list. Webhooks, code access and commit status are created for you.

  • GitHub App from a manifest. Click "Connect GitHub", confirm the name, install. Each install gets its own app and keys.
  • GitLab with one token. GitLab.com or self-managed. A test button checks the scopes, and the panel warns 14 days before the token expires.
  • Verified webhooks. HMAC signatures for GitHub and a secret per project for GitLab. Anything else is rejected.
  • Status on every commit. Building, live or failed, on both services.
meridian/api main
  • Add rate limit headers 3f9c2a1 nocap: live
  • Fix pagination cursor a81e07d nocap: live
  • × Try new HTTP client 5c42b9e nocap: failed
03 v0.1

Domains and HTTPS

Add a domain to an app and point its DNS at your server. Traefik routes the traffic and gets a Let's Encrypt certificate, then renews it before it expires.

  • Several domains per app, HTTP always redirected to HTTPS.
  • The panel itself can live on its own domain.
  • Clear errors when DNS does not point to the server yet.
Domains
  • meridian.example Certificate valid
  • www.meridian.example Redirects to meridian.example
  • api.meridian.example Getting certificate
04 v0.1

Reliability

A broken deploy should never take the working version offline. Every deploy follows the same safe path.

  1. Step 1

    Build

    The new image is built while the old one keeps serving.

  2. Step 2

    Health check

    The new container must answer on its health URL.

  3. Step 3

    Swap

    Traffic moves over. Nobody sees an error page.

  4. Anytime

    Roll back

    Any of the last 5 images, in one click.

Encrypted variables. AES-256-GCM before they reach the database.

CPU and RAM limits per app, so one app cannot starve the rest.

Weekly cleanup of old images and build cache, so the disk never fills up.

05 v0.1

Databases and backups

Start a database next to your app in one click, on a private network. Link it and the connection string arrives as an environment variable.

  • PostgreSQL, MySQL, MariaDB, MongoDB and Redis, with no public port.
  • Migrations run before every release, with presets for Prisma, Django, Laravel, Rails, Spring Boot and more. If they fail, the current version keeps serving.
  • Scheduled backups to any S3-compatible storage: Amazon S3, Cloudflare R2, MinIO.
  • Restore from the panel. Every release is tested by restoring a real backup.
meridian-db backups Daily at 03:00 · R2
  • Today, 03:0048.2 MBRestore
  • Yesterday, 03:0047.9 MBRestore
  • 2 days ago, 03:0047.5 MBRestore
06 v0.1

Updates without SSH

The panel checks for new releases once a day. Click update and it pulls the new images, runs the migrations and restarts. If the new version fails its health check, the previous one comes back.

Nocap Cloud v0.2.0 is available

You are on v0.1.0. Monitoring, notifications and remote access.

Update now
07 Works today

Security first

The panel controls Docker on your server, so it is built to be hard to break into. These protections are already in the code.

08

Light by design

Fewer moving parts means less memory, fewer things to back up and fewer things to break. Every choice below keeps the footprint small.

We use Instead of Saves
Panel, API and worker in one image Three separate images Two containers and their idle memory
Job queue inside Postgres Redis with a queue library One container and one more thing to back up
Panel served by the same Node process A separate web server One container
Alpine image, bundled server Full Node image with all dependencies A smaller download and a faster install
Logs on disk with rotation Logs in the database The database stays small

Targets for v0.1, checked on every release: idle memory under 400 MB for the whole stack, the Nocap image under 200 MB, and install under 2 minutes on a 2-vCPU server. These are goals we measure, not results yet.

After v0.1

Coming soon

Each version after the first release adds more, without adding containers. Vote on the order.