Your servers finally have a deploy button.
Nexploy turns a Linux box with Docker into a deployment platform. Push to a branch and it builds the image, starts the container, attaches the Traefik route and issues the certificate — then hands you the whole Docker surface to run what it just shipped.
one command · five containers · about a minute
- █
a real deploy, start to finish — no cloud account involved
- 63
- node types in the pipeline editor
- 5
- Git providers, webhooks wired for you
- 5
- containers, from one install command
- €0
- per deploy, per seat, per GB out
why nexploy
You already pay for servers. Use them.
Cloud platforms sell you a workflow and then bill you for growing into it. Nexploy gives you the same push-to-deploy loop and leaves the meter off.
The bill stops moving
One server runs as many projects, seats and builds as it can fit. No per-seat pricing, no build minutes, no egress invoice after a week that went well.
Nothing to migrate off
Standard Docker images, a standard Git repository, a Dockerfile you wrote. Leaving means pointing them at another host — there is no proprietary format in the middle.
The machine stays visible
Containers, images, volumes, networks, Swarm services, Traefik routes, live logs and a shell inside the container. Nexploy runs your infrastructure without hiding it from you.
source/webhook-clone
Set it up once. After that, just push.
No pipeline file to write, no runner to register, no cloud console to learn. A repository with a Dockerfile — or a compose file — is the entire setup.
Authorize your Git provider
GitHub through a GitHub App; GitLab, Gitea, Bitbucket and Azure Repos over OAuth — self-hosted GitLab and Gitea included. Nexploy registers the webhook itself — there is nothing to paste into a settings page, and the token is stored encrypted and refreshed for you. A public repository needs none of that — pick the custom URL mode and paste its address and Nexploy reads the branches straight off the remote.
oauth · github app → webhook registered
Pick the repository, branch and domain
Choose the stage it deploys to and the domain it answers on. Environment variables are encrypted with AES-256 the moment you save them, and decrypted only to be written into the build.
main → app.example.io
Push
Every commit runs the stage pipeline: build the image, start the container, attach the route, issue the certificate. Logs and per-node timings are kept for every build, successful or not.
git push origin main
build/build-docker-image
Wire the pipeline. Don’t write the YAML.
Drag nodes onto a canvas and connect them. Nexploy runs the graph one durable step per node and streams the status and duration of each one back onto the canvas while it executes. 63 node types ship with the editor, and every one of them does the real thing.
Clone via webhook
webhook-clone
Build image
build-docker-image
Scan image
scan-image
Deploy Compose
deploy-compose
Save the version
save-version
The full palette
63 node types · 10 categories
Source
- clone-repository
- webhook-clone
- merge-branch
Build
- build-docker-image
- set-runner
- push-to-registry
Deploy
- deploy-compose
- create-service
- scale-service
Flow
- condition
- wait-for-health
- wait-for-url
Utility
- save-version
- create-volume
- prune-containers
Integration
- send-notification
- http-request
- create-release
Files
- cache-save
- cache-restore
- download-file
Config
- set-env-vars
- fetch-secrets-vault
- fetch-secrets-doppler
Script
- run-command-in-container
Database
- backup-volume-bucket-storage
Two templates ship with the editor — Dockerfile and Compose — so the default path is one click, and the assistant can read a repository and draw the whole graph when neither template fits. The graph is snapshotted onto the build when it starts, which means editing a pipeline never rewrites the history of past builds.
deploy/trigger-stage-build
Staging and production, out of one repository.
A stage is a full deployment target: its own pipeline, environment variables, Docker host, domain and version history. Promote by triggering the next stage from the graph, roll back by picking a version that already worked.
- host
- tcp://build-01:2376 · TLS
- domain
- staging.example.io
- env
- 14 variables
- host
- unix:///var/run/docker.sock
- domain
- app.example.io
- env
- 22 variables
A pipeline per stage
Staging can scan, seed and notify while production only builds and deploys. Each stage keeps its own graph, its own environment variables and its own build history.
A Docker host per stage
Local socket, TCP, or TCP with TLS. Staging on the box next door, production on the cluster — same repository, same interface.
Versions you can walk back
Every deploy can save a version. Rolling back is picking an earlier one, not rebuilding an old commit and hoping the image comes out identical.
build/set-runner
Builds move off the machine serving your users.
Register a build server, drop a set-runner node in the graph, and the clone, the build and the push happen on a machine you keep for that. Production only does a docker pull.
- runs
- pipeline, gateway
- builds
- nothing
- pulls
- the finished image
- clone
- shallow, credentials per job
- build
- docker build
- push
- to your registry
Outbound only
The runner dials your server over WebSocket and waits for jobs. No inbound port, no Docker socket on the network. A spare box behind a home router qualifies.
One node, the whole branch
Drop set-runner in the graph and every build below it moves. Compose stacks split cleanly: services you build go to the runner, services on a public image keep pulling from their public repo.
A way back
Runner offline, disabled, out of slots — the build either falls back to the Nexploy server with a warning in the log, or fails outright. You pick, per node.
The image has to reach production somehow, so a runner needs a registry — yours, or a local one Nexploy creates for you in a click.
utility/create-volume
It keeps being useful after the deploy.
Most platforms hand you a URL and hide the machine. Nexploy hands you the URL and the machine: the whole Docker and Swarm surface, in the same interface that built the image.
Containers & images
Create, inspect, restart, stop, prune. Live stats, logs and events for everything running on the host.
Volumes & networks
The parts nobody wants to manage over SSH: create them, attach them, see what is using them, clean them up.
Services & nodes
Scale replicas from the screen that deployed them, update a service in place, and watch the tasks reschedule across nodes.
Compose stacks
Deploy a multi-service stack straight from the compose file already sitting in the repository — validated before it runs.
Domains, SSL & DNS
Routes are generated per repository. Point a domain at it and Let's Encrypt issues and renews the certificate — or bring your own. DNS records are written for you at Cloudflare, OVH, Hetzner, DigitalOcean, Vultr, Linode, Porkbun or your own PowerDNS.
Scheduled backups
Volume snapshots on the schedule you set, pushed to AWS S3, MinIO, Cloudflare R2 or anything that speaks the same protocol.
Private registries
Pull base images and push builds to Docker Hub, GHCR or a registry you run yourself, with credentials stored encrypted.
Automatic cleanup
Scheduled prune of dangling images, unused volumes, dead containers and build cache, so the disk stops being a surprise.
flow/wait-for-health
Watch it happen. Then go in and fix it.
Build logs, container stats, Docker events and Traefik requests all arrive over one SSE connection. There is no refresh button because there is nothing to refresh. And when reading is not enough, open a shell inside the running container, from the browser.
12:04:03 Step 4/9 · COPY . .
12:04:22 Step 7/9 · RUN pnpm build
12:04:38 Image built · 128 MB · 41.2s
12:04:41 Traefik · route app.example.io attached
12:04:42 Let's Encrypt · certificate issued
12:04:43 Container healthy · traffic switched
█
/app # ls
Dockerfile package.json src/
/app # node -v
v22.13.0
/app # cat /proc/loadavg
0.14 0.09 0.08 1/218 41
/app # █
script/run-command-in-container
An assistant that can actually reach the infrastructure.
It reads the live state of your containers, builds, domains and pipelines through an MCP server — 68 tools in 12 groups — then diagnoses, scales, redeploys, rolls back, or draws a whole pipeline for a repository it has just read. The same server answers Cursor and Claude Desktop. Bring your own provider and your own key: the prompts never pass through us.
Bring your own model
Your key, your provider, your bill. Nexploy stores the key encrypted and calls the provider directly from your instance.
What it can touch
containers10
repositories9
swarm8
images7
compose6
environments6
volumes5
networks4
registries4
ssl4
pipeline4
confirm1
The api container keeps restarting. What is wrong, and can you fix it?
Its healthcheck has failed since last night’s deploy — the logs stop at ECONNREFUSED 5432. The database host in the production variables still points at the old container. Two calls fix it:
setEnvVariables · api · production
recreateContainer · api
Confirmation required
recreateContainer restarts a container serving production traffic.
It can draw the pipeline for you
Ask for a pipeline and it reads the repository first — the fourteen config files that give a stack away, from Dockerfile and docker-compose.yml to go.mod, pyproject.toml and pom.xml — picks the nodes that match what it found, and saves a complete graph you open in the editor and edit by hand.
analyzeRepository · api · main
listPipelineNodes
savePipeline · 7 nodes
Or drive it from your own editor
The MCP server is exposed as an endpoint on your instance. Point any MCP client at it, sign in with OAuth or a scoped API key, and the same 68 tools show up where you already work.
https://your-instance/api/mcp
Reads happen freely. Anything that changes something running — a rollback, a scale, a delete — stops and waits for a yes, and every call is still checked against the same permissions as the person asking.
config/fetch-secrets-vault
Your code never leaves the building.
Source, images, environment variables and logs stay on machines you control — and the controls that protect them are on by default, not sold back to you as an upgrade.
- Environment variables encrypted at rest
- AES-256-GCM — authenticated, so tampering is detected, not just hidden — before they touch the disk, decrypted only to be written into the build that needs them.
- Git credentials stored encrypted, refreshed for you
- OAuth tokens are encrypted at rest and renewed automatically, so a build never fails because a token quietly expired.
- Two-factor on any account, invite-only by default
- Email and password, with TOTP and backup codes, plus API keys for automation — none of it reserved for a paid tier. Public sign-up is off: accounts exist because an admin created them.
- Two role systems, both enforced on every action
- The instance role — guest, developer, admin — authorizes a type of action. The organization role — owner, admin, member — grants access to the specific repository. Both have to allow it.
- Lock a Docker host down, action by action
- Mark an environment protected and pick what it refuses — deletions, terminal access, deployments, Swarm changes. The block holds on the server actions, the Docker API and the AI tools alike, and it can be set to stop administrators too.
- A recovery CLI for the bad day
- nexploy-cli talks straight to the instance database, so a lost admin password is fixable even when the app itself will not start.
- instance role
- developer
- organization
- acme · owner
- two-factor
- TOTP · 10 backup codes
- api keys
- 2 active
compare
Same push-to-deploy. A lot more underneath.
Everything you use a cloud platform for, plus the pipeline editor, the stages, the Swarm orchestration and the assistant they do not offer — on servers you own, instead of a bill you do not control.
| Capability | Nexploy | Vercel / Netlify |
|---|---|---|
| Push to main, the app goes live | ||
| Automatic SSL and reverse proxy | ||
| Build logs streaming in real time | ||
| Visual pipeline editor, 63 real node types | ||
| Stages with their own pipeline, host and versions | ||
| The whole Docker surface: images, volumes, networks | ||
| Docker Swarm orchestration and scaling | ||
| Shell into a running container from the browser | ||
| Scheduled volume backups, plus export and import by hand | ||
| An assistant wired to your live infrastructure | ||
| Source and images never leave your network | ||
| Fixed cost, no usage-based billing |
What they still do better: a global edge network, serverless functions and someone else’s on-call rotation. Nexploy is the other trade — one machine you understand, instead of a platform you rent.
pricing
Free on your box. Priced later on ours.
Nexploy is open source, and that is the whole offer today. Install it on a server you already pay for and it costs nothing — no seat count, no build minutes, no feature held back for a higher tier.
Self-hosted
Available now€0/ forever
- Every feature on this page, no tier gating
- Unlimited repositories, stages, users and builds
- Upgrade with one command, your data untouched
requires a Linux server with Docker, root, and ports 80 and 443 free
Managed instances
Coming soonStarter · Pro · Business · Enterprise
Same Nexploy — you just do not bring the server. You pay a monthly subscription and we hand over a machine that already runs it.
Pick a size
CPU, RAM and disk. That is the only choice you make.
We hand you the server
A dedicated VPS with Nexploy already installed, patched and backed up.
One bill a month
Server and software on a single subscription. Cancel whenever.
pricing
Lands with the launch. Whatever you build on the free version moves to a managed instance — or back to your own hardware — unchanged.
later, on the same subscription
- Managed databases and storage
- One-click backups and restores
- Multi-server deploys
questions
The parts people ask about twice.
Straight answers about what it takes to run Nexploy, what it does with your code, and how you get out.
One command from here.
Point it at a server you already pay for. It installs Docker if it has to, asks for a domain and how you want HTTPS — Let’s Encrypt, or a certificate you paste in — generates every secret, writes the Traefik configuration and starts five containers. Then you connect a repository and push.
upgrading later