Skip to content
nocapcloud

Roadmap

A tree that grows one version at a time.

The trunk is the main branch. Each version is a branch, and its features are the leaves. Filled leaves are done. Pre-releases grow on a side branch and join the trunk at v0.1, the first release you can install.

v0.0.1 you are here v0.0.2 v0.0.3 v0.0.4 v0.0.5 v0.1.0 v0.2 v0.3 v0.4 v0.5 v0.6 v1.0 main pre-releases
In progress Next Planned Later Leaf done Leaf to do
v0.0.1 In progress Pre-release

Foundations

8 of 9
  • Public repository, Apache 2.0 and community files
  • CI: format, lint, types, tests, build and Docker image
  • Admin login with argon2, sessions and rate limits
  • First-run setup that creates the admin
  • Projects: create, search, rename and delete
  • Black and white panel with light and dark themes
  • Install script and the three-container stack
  • Website, live demo and protected main branch
  • Install tested on a clean Ubuntu server

Done when one command installs everything on a clean Ubuntu server and the login works.

v0.0.2 Next Pre-release

Deploy

  • Docker layer: build, run, stop, remove and logs
  • Build queue in Postgres, one build at a time
  • Clone a public repository, last commit only
  • Build from a Dockerfile or Docker Compose
  • Traefik routing with Let's Encrypt certificates
  • Screens for applications and domains
  • Build and runtime logs, live over WebSocket
  • Deploy, restart and stop buttons

Done when a public test app is live over HTTPS and its logs stream in real time.

v0.0.3 Planned Pre-release

Git connection

  • GitHub App created from a manifest in a few clicks
  • GitLab token with a "Test connection" button
  • Webhooks and deploy keys created by the API
  • Repository and branch pickers with search
  • Detect Dockerfile, Compose file and port
  • Verified webhooks and status on every commit
  • Warning before a GitLab token expires

Done when a push on GitHub and another on GitLab deploy by themselves.

v0.0.4 Planned Pre-release

Reliability

  • Variables encrypted with AES-256-GCM
  • Health check per app
  • Zero-downtime swap after the health check
  • Rollback to any of the last 5 images
  • CPU and RAM limits per app
  • Weekly cleanup of old images and builds

Done when a deploy broken on purpose does not take the previous version offline.

v0.0.5 Planned Pre-release

Databases and backups

  • One-click PostgreSQL, MySQL, MariaDB, MongoDB and Redis
  • Link a database to an app as a variable
  • Release command for migrations, with framework presets
  • Scheduled backups to S3, R2 or MinIO
  • Restore from the panel, tested on a real backup
  • A real production app running on Nocap for a week

Done when a production app runs on Nocap with a daily backup that was restored once.

v0.1.0 Planned First release

Install it anywhere

The pre-release branch joins the trunk. Everything above, packaged and documented.

  • Images for amd64 and arm64 on GitHub Container Registry
  • One-line installer at get.nocapcloud.click
  • Updates from the panel, with automatic rollback
  • Documentation site
  • Security review of login and webhooks
  • Launch post and a short demo video

Done when someone installs it from the README on a fresh server and deploys an app without asking for help.

v0.2 Planned

Monitoring and alerts

  • CPU, RAM, disk and network per app and per server
  • Alerts by email, Slack, Discord and Telegram
  • MariaDB and MongoDB
v0.3 Planned

Templates and previews

  • One-click templates: n8n, Plausible, Uptime Kuma and more
  • A preview deployment for every pull request
  • Scheduled jobs
v0.4 Planned

Teams and API

  • Teams and roles
  • Two-factor login
  • API tokens and a command-line tool
v0.5 Planned

Multi-server

  • Deploy to other servers over SSH from one panel
  • Optional Docker Swarm
v0.6 Planned

No Dockerfile needed

  • Builds with Nixpacks or buildpacks
  • Backups of app volumes
v1.0 Later

Stable

  • A stable API, with breaking changes only in major versions
  • A safe upgrade path from every 0.x release
  • Whatever the community votes to the top

The order after v0.1 follows what people ask for. Vote on the ideas.

Releases

How a version ships

  1. 1. Tag

    A version tag on main

    Semantic versions. v0.x until the API is stable.

  2. 2. Build

    Images for two CPUs

    GitHub Actions builds amd64 and arm64 and pushes to GHCR.

  3. 3. Publish

    Release notes

    A GitHub Release with the changelog, installer and compose file.

  4. 4. Update

    One click for you

    Your panel shows the update and installs it without SSH.