From Dokploy to Noust

For someone who runs Dokploy and wants to know what Noust does differently, what each Dokploy screen and setting is called here, what is not done on purpose, and how to move. It is written from Dokploy's own code and documentation (the 0.2x line, read at its repository's current main) and from Noust's; where something here is a choice of design, it says so.

The difference that explains the rest

Dokploy runs everything in Docker, on Docker Swarm: each application is built into an image (with Nixpacks, Railpack, Heroku or Paketo buildpacks, a Dockerfile, or a static server), runs as a Swarm service behind Traefik, which Dokploy writes the configuration of. A server is a Swarm node; several servers are a Swarm cluster. Noust runs applications as ordinary processes under systemd, behind the nginx or Apache the server already has, with a certificate from Let's Encrypt through certbot. Docker is only there when a project is a Docker Compose project, a Dockerfile or an image (then Noust runs it as a unit too).

What follows from that:

• No Swarm, no replicas, no placement. One server is one server. Several servers are a fleet, each with its own applications and its own Noust (CENTRAL.md); nothing balances an application over them.
• No Traefik. The web server is the proxy and its site files are plain text you can read and edit (domains.md). Dokploy's Traefik File System page has no counterpart because there is no second configuration language.
• Every deploy is a release on disk, switched only if the new version passes a health gate; rollback is flipping a link back, with no registry in between. Dokploy's rollbacks keep images (and need a registry to keep them somewhere).
• Two interfaces to the same thing: the console and the noust command, both clients of the same code. --dry-run rehearses any command; --json makes it scriptable.

Concepts

Screens

Where each page of Dokploy's sidebar is in the console. Everything in Noust's list is in the command palette (Ctrl K) too.

What Noust does not do, on purpose

• No Swarm. One server is one server; several are a fleet.
• No proxy to choose or configure. nginx or Apache, with sites you can read.
• No image registry in the path of a native deploy. A release is a directory; a container application keeps its images on the server and can push them to a registry you name.
• No cluster of build nodes that a deploy is spread over. A build can run on one server and be served from another (delivery.md); that is one build, shipped.
• No licensed tier. Dokploy's Billing, License, SSO and Whitelabeling pages belong to its commercial parts (the code under a proprietary folder of its repository has a separate licence). Noust's single sign-on, audit trail, teams, roles and approvals are part of the one edition.
• No telemetry or error reporting to third parties. The requests Noust makes on its own are the update check (updates.check: false turns it off) and the ones you configure.

Moving across

Dokploy keeps an application's configuration in its own database, not in the repository. Noust reads it from Dokploy's API instead: in the console, New application > Import an application under From another platform, or on the command line:

# an API key made under Dokploy's Settings > API Keys, in a file only you read
noust import --from dokploy --url https://dokploy.example.com --token-file dokploy.key
noust import --from dokploy --url https://dokploy.example.com --token-file dokploy.key --app shop
noust import --from dokploy --url https://dokploy.example.com --token-file dokploy.key --app shop \
  --deploy shop.example.com --env-file shop.env

The key is used for those requests and kept nowhere. What carries over: the repository and branch (GitHub, GitLab, Bitbucket or a plain git URL), the build path, the publish directory of a static site, the domains and the port, the variables (the ones whose value looks like a credential are asked for again, so a connection string that names a Dokploy database is not carried to a place it cannot reach), the watch paths, submodules, the memory and processor limits, the volumes and bind mounts (as --persist paths where they sit under /app, with the command that copies the data out of the old server and the one that puts it back) and the databases of the same environment that a variable names, with the docker exec dump and the noust db import that loads it. What is only said, with what to do instead: Swarm settings, an application that runs an image or a Dockerfile (the noust create command that creates it is given), a Gitea source, an uploaded archive, and a file Dokploy writes and mounts.

The same path by hand is mechanical, and each step is checked by Noust:

1. Install Noust on a new server (cloud-init.md, PLATFORMS.md).
2. Deploy the application from its repository: noust create -d app.example.com -s https://github.com/you/app.git --env-file app.env --persist uploads. A Nixpacks application is detected by its files like any other; a Dockerfile application is --type container.
3. Check it before moving the name: curl --resolve app.example.com:443:NEW-IP https://app.example.com/, and noust diagnose app.example.com. Dokploy's copy keeps serving the real name meanwhile.
4. Move the data. A database that Dokploy runs is dumped where it runs (docker exec ... pg_dump, the importer prints the command) and loaded with noust db import NAME FILE -e postgresql; a volume is copied with the tar pair the importer prints.
5. Move DNS, then turn Dokploy's service off. Keep its backup until Noust's schedule has made and verified a few of its own: noust backup schedule create and noust backup verify.

A template from Dokploy's catalogue

Dokploy's one-click templates (https://github.com/Dokploy/templates, MIT) are a folder per application: a docker-compose.yml and a template.toml with variables written as expressions (${password:32}, ${hash:8}, ${base64:32}, ${uuid}, ${domain}, ${jwt:secret:payload}, ...), the domains, and files to write beside the stack. Noust converts one into a stack it deploys:

git clone --depth 1 https://github.com/Dokploy/templates.git
noust compose import templates/blueprints/ghost --from dokploy \
  --domain blog.example.com --out ./blog
noust create -d blog.example.com -s ./blog

The command line and the API do this; the console's New application > Compose > Convert a template reads Coolify's format only, because a Dokploy template can carry files to write beside the stack and the console's form has one document. API: POST /api/compose/import with "format": "dokploy", the Compose text in document and the template.toml in template; the answer lists the files and, apart, the ones that hold a secret (secret_files).

• The expressions are expanded the way Dokploy's own processor does it, with Noust's generators: ${password:N} is N lower-case letters and digits, ${hash:N} N hexadecimal digits, ${base64:N} the base64 of N random bytes, ${jwt:secret:payload} a token signed with the variable secret and carrying the JSON in payload (with Dokploy's iss, iat and exp when the payload has none). The values go to .env (mode 0600), never to the screen.
• The domain. A template that builds its addresses from ${domain} needs --domain. The service its [[config.domains]] names is published on 127.0.0.1 (127.0.0.1:${PORT:-8080}:8080), which is how Noust's web server reaches a stack; a second service, another host name or a path is said, never guessed.
• The files its [[config.mounts]] write are written under files/ beside the document, and the Compose file's ../files/x becomes ./files/x. A path that leaves the folder is refused. A file that holds a generated secret is written readable by its owner only.
• What means nothing here is dropped, and said: dokploy-network, Traefik labels, the isolated deployment. The restart policy, the declaration of the named volumes and the ${NAME} spelling are what Compose needs and Dokploy did.
• The result is judged like any Compose file (noust compose check): a template that mounts the Docker socket, runs privileged or mounts the host's root is refused, as a repository's would be.

python scripts/template_catalogue.py dokploy PATH/TO/templates/blueprints converts a whole checkout and prints the figures. On the catalogue at the time of writing (572 templates), 541 convert to a document nothing refuses and 31 are refused for what the guard refuses in any Compose file: the Docker socket (27), a directory that holds Noust's own state (2), a privileged container (1), a build context (1). The templates are MIT (Copyright 2024 Dokploy and Carlos Ortiz); a template's own authors keep their rights in it. Noust ships none of them: you bring the files, the converted document says where it came from, and the logos a template names are not fetched.

Moving the other way

noust app export APP -o app.json writes everything that defines an application as JSON, and noust app import deploys it on another Noust. Nothing Noust keeps is in a format only Noust can read: the sites are nginx files, the units are systemd units, the backups are .tar.gz files with checksums, and the database dumps are the engine's own (leaving.md).