The design is deliberately simple: a hosted control plane over a server you own, with a native runtime and no required containers.
The parts:
- Control plane: hosted by DollarDeploy; orchestrates builds and deploys, holds no lock on your app.
- Data plane: your server, in your provider account.
- Runtime: native systemd services on Linux by default; Docker Compose optional.
- Ingress: managed reverse proxy plus HTTPS via Let's Encrypt.
- Delivery: GitHub repo -> build -> your server, with deploys on push and one-action rollback.
- Interfaces: web UI, CLI, API, and an MCP server.
- Databases: managed PostgreSQL, Redis, MongoDB, MariaDB on your server.
Why it matters: no Kubernetes and no required container layer. Native systemd is the differentiator, with lower overhead and Docker available when an app needs it.
Ownership model:
- Code: yours, stored in your GitHub repository.
- Application infrastructure: yours, running in your VPS/cloud-provider account.
- Applications and databases: run on infrastructure you control.
- Control plane: hosted and operated by DollarDeploy.
This differs from a managed PaaS, where both the control plane and application runtime are operated by the platform, and from a self-hosted PaaS, where you operate both.
Build architecture:
DollarDeploy separates application builds from the application runtime for supported native deployments.
Native applications can be built using DollarDeploy's build infrastructure and the resulting application deployed to the customer's server. This avoids consuming the application server's CPU and RAM during resource-intensive builds.
This is particularly useful on small VPS instances where builds for applications such as Next.js can temporarily require significantly more memory or CPU than the running application itself.
Docker-based workloads follow their applicable Docker build and deployment workflow.
Go deeper: running Node.js apps as systemd processes and how we do atomic deploys.