All work

Product

Stackport

Your VPS. All your apps. None of the busywork.

For developers who already pay for a VPS and run more than one app on it. Stackport deploys Docker Compose projects from GitHub with HTTPS, records deployments for rollback and shows service status. I use it to operate this site and other MattediWorks web services on my VPS.

Open source · self-hosted

WebsiteGitHub

From repository to running service

Connect a GitHub repository and branch, deploy its Docker Compose services, then route a domain to the service that should receive traffic. The same console keeps the deployed commit, health, logs and container terminal close to the app.

In use at MattediWorks

Team
Solo, design to deploy
Period
2026-09 – now
Status
In daily use for MattediWorks services
Stack
TypeScript, Node.js, Express, React, SQLite, Docker

Deploy, inspect, restore

  • Push to deploy

    Connect a GitHub repository and pick a branch. New commits become deployments pinned to the exact commit.

  • HTTPS, handled

    Point a domain at a service and port. nginx and Let's Encrypt certificates, issued and renewed, are taken care of.

  • Rollback with confidence

    Every successful deploy records its source, Compose config, branch and commit, ready to restore.

  • Know what is alive

    Health checks, response time, CPU, memory and container state on one dashboard, plus logs and a terminal in the browser.

  • Deployment policy checks

    The deployment policy rejects Compose files that publish host ports, use host networking, request privileged containers or mount blocked host paths.

  • Ready for agents

    An MCP server lets your AI agent check status, projects and recent deployments.

Keeping one host manageable

  • No host ports, fail-closed

    A project whose Compose file publishes a port or uses host networking is rejected at deploy time, with an error that points to expose:. Stackport decides what the host exposes, not the project. It costs some friction when adapting a repo, and removes a whole class of accidental exposure.

  • A domain routes to a service and port, not to a project

    Each domain maps to one (service, container port) pair inside a project, so one project can serve its web app on one domain and its admin API on another. The networking change that makes this work is an ephemeral rewrite of the Compose file, never committed to the project's repo.

  • Everything in Docker, nothing installed on the host

    No host nginx, Certbot or Node.js: the host only needs Docker, the CLI and two state directories. nginx configuration is generated, validated and rolled back if it fails, so a bad domain never takes the proxy down for the other projects.

System services and managed apps

Traffic from the internet reaches stackport-nginx, which serves the Stackport app (admin UI, API and MCP) and proxies each deployed project over the stackport-proxy network. Stackport drives the Docker Engine to deploy and run the projects, each one a Compose project of its own.System planestackport-proxy80 · 443admin · API · MCPdeployInternetHTTP/S · TCPStackportExpress · React · SQLitestackport-nginxTLS · Let's EncryptDocker Enginecompose · logs · execProject Aown Compose projectProject Bown Compose project
  • Node/Express backend and React client in TypeScript; state in SQLite.
  • System plane (Stackport and its nginx) is one Compose project; every deployed project is a separate one.
  • Projects join a shared stackport-proxy network; nginx reaches them by service name.
  • A stackport CLI handles install, upgrade and admin recovery on the host.
  • MCP server for agents. A companion project, Stackport MQTT, runs the TLS-only Mosquitto broker for the NightMare devices and its controller API in Go.

Where the platform stops

  • One host: no scheduling across machines.
  • Health shows "unknown" for projects without a configured health check.