NomployNomploy

Deployment Options

Nomploy Server vs Remote Servers vs Cluster: choose where your applications run.

Nomploy gives you three ways to run your applications. All of them use the same deployment engine — the difference is where your apps run and how the servers relate to each other.

  1. Nomploy Server: everything runs on the same machine where the Nomploy UI is installed.
  2. Remote Servers: independent servers connected via SSH, each running its own apps.
  3. Cluster (Multi-node): additional machines joined into the Nomploy cluster (Nomad + Consul over a WireGuard mesh) to run and replicate applications across servers.

Nomploy Server

This is the default. When you install Nomploy, the UI, the builds, and your applications all run on the same server.

  • No extra configuration: deploy immediately after installation.
  • Scaling: vertical — add more CPU and RAM through your VPS provider.
  • Best for: most users. It's the simplest option and the recommended starting point; only move to the other options when a single server is no longer enough.

Remote Servers

Remote Servers are independent machines that Nomploy manages over SSH. Each remote server runs its own standalone Docker and its own Traefik instance — they don't form a cluster and don't know about each other.

  • Isolation: each server is independent. If one goes down, apps on other servers are unaffected, and your apps don't compete for resources with the Nomploy UI.
  • Two types: deployment servers run your apps, and build servers only build images and push them to a registry.
  • Requirements: SSH access to each server. A Docker registry is only needed if you use build servers.
  • Best for: separating apps per environment, region, or customer; keeping the Nomploy UI on a small server while apps run elsewhere.

Cluster (Multi-node)

The Cluster feature joins additional machines as server or worker nodes, connected through an encrypted WireGuard mesh. Nomad schedules workloads across the nodes and Traefik (via the Consul Catalog) routes traffic to wherever they run.

  • Replication & capacity: run workloads across multiple machines, with routing handled by Traefik.
  • High availability: with 3 or more server nodes, the scheduler tolerates node failures.
  • Requirements: a container registry so every node can pull your images (registry auth is distributed cluster-wide via Consul), and network reachability for the WireGuard mesh.
  • Trade-offs: more setup and operational complexity, and Nomploy does not perform automatic storage cleanup on the extra nodes.
  • Best for: horizontally scaling across machines and high availability of the scheduler.

Comparison

Nomploy ServerRemote ServersCluster (Multi-node)
Where apps runSame machine as the UIIndependent serversAcross cluster nodes
Connection—SSHWireGuard mesh
Docker registry requiredNoOnly for build serversYes
Isolation between servers—High (fully independent)Low (shared cluster)
Replicas across serversNoNoYes
High availabilityNoNoYes (3+ servers)
Automatic storage cleanupYesYes (configurable)No
Setup complexityNoneLowHigh

Which one should I choose?

  • Start with the Nomploy Server and scale vertically (more CPU/RAM). It covers the vast majority of use cases with zero extra configuration.
  • Use Remote Servers when you want isolation: production apps separated from the Nomploy UI, different servers per project or region, or a dedicated build server.
  • Use a Cluster when you need to run or replicate workloads across multiple machines, or want high availability of the scheduler.

These options are not mutually exclusive. A common setup is a small server running only the Nomploy UI, with applications deployed to remote servers. You can also add a cluster node as a remote server to configure storage cleanups on it.

On this page