Skip to content
GitHub 6 Install

Deploy anything. Break nothing.

A free, open-source panel for deploying to your own Linux servers.

curl -fsSL https://noust.dev/install.sh | sh

Run it as root on a fresh server: it installs nginx, certbot, git and Node.js. Check the script first.

The Noust console on the page of the application wrenfield.io: status Running, deployment #4 live, and the list of recent deployments, in which #5 is marked Failed.
  1. #5 starts beside #4 Noust asks it for the home page every 2 s
  2. #5 answers 500 for 30 s The check fails and no visitor is sent to it
  3. #4 is still live Every request was served by #4

Three measured facts

  • 52s

    from apt install to a first app answering over HTTPS, in our test

    • apt install 22.1 s
    • setup 19.4 s
    • the first app and its certificate 10.4 s

    Noust 3.3.1, before 4.0, in a Debian 13 container, on a 14-core laptop, 20 Oct 2026. The package came from a local file and Pebble, Let’s Encrypt’s test server, issued the certificate, so a real server takes longer.

    The measurement file
  • 199

    tested apps that install with one command

    On 28 and 29 Oct 2026 we started each recipe on a clean server, with the development code that followed Noust 4.0.0, and every one passed its health check. A recipe's whole test, image download included, takes 54 s at the median.

    Results per app
  • 18

    Linux releases the installer is tested on

    From packages: Debian 12 and 13; Ubuntu 22.04, 24.04 and 26.04; Fedora 43; openSUSE Leap 16.0 and Tumbleweed. With pip: Rocky Linux, AlmaLinux, RHEL, CentOS Stream and Oracle Linux, versions 9 and 10.

    Platforms

Noust in a minute

From a repository to HTTPS, a database for it, a broken release that never takes traffic, and every server in one console. Recorded as it happened in the console, with no sound.

What the video shows
  1. On the central, Marta starts a new application on fra-1 and types the repository kelmoor-labs/tidewick-site. Noust recognises a Next.js site; she types tidewick.io and the console checks that it points at the server.
  2. She deploys it and follows it live: fetch, install, build, start, and a check that it answers. tidewick.io is running, over HTTPS.
  3. She creates a PostgreSQL database for it. Noust links it as DATABASE_URL.
  4. She finds the shop with the search. Iker pushes a change to shop.brumaria.es: the release never answers its startup check, so the app goes back to version #21 and the shop keeps running.
  5. From the server selector, the whole fleet: fra-1, ams-3 and lon-2 answering, what needs attention on each, and their CPU, memory and disk side by side.

Every deploy is health-checked, and a failed one is undone

Each release is built beside the live one and only replaces it once it passes its health check. That holds for Node.js, Next.js, Python and Vite apps created since 4.0; the others are below.

An animation of two deploys of wrenfield.io in a row. Visitors keep arriving through nginx at the live release, #3. Release #4 is built beside it on its own port, and Noust asks it for the home page every 2 seconds; it answers 200 three times, so nginx sends new visitors to #4, and #3 finishes the requests it had and stops. Then release #5 is built beside #4 and checked the same way; it answers 500 three times, so it is marked failed and stopped. No visitor ever reached it, and #4 kept serving without a restart.
  1. 1. Built beside the live release

    The new release gets a directory of its own and is built by an unprivileged account, noust-build. The live one keeps serving.

  2. 2. Health-checked on its own port

    Noust requests the home page every 2 s for up to 30 s, and any HTTP status below 500 passes. You can change the path, the statuses and the timeout.

  3. 3. If it passes, it gets the traffic

    nginx sends new requests to the new release, and the old one finishes the ones in flight, then stops.

  4. 4. If it fails, #4 keeps serving

    #5 is stopped and #4 never restarted. The deployment keeps the check’s output and the journal.

What a failed deploy leaves

The health check’s output as Noust writes it, and the last lines of the app’s journal, as the page of deployment #5 shows them.

The application did not answer the health check.

Health check attempts 1-15 failed: HTTP 500 is not an expected status

Last lines of the journal of wrenfield-io.service:
Oct 29 10:16:02 fra-1 wrenfield-io[52114]: Error: Cannot find module './lib/image-loader'
Oct 29 10:16:02 fra-1 wrenfield-io[52114]: Require stack: .next/server/app/page.js

Other apps are health-checked too

A static site switches one link and a PHP app reloads PHP-FPM, with nothing restarted. Other apps that keep their earlier releases, and Compose stacks, are restarted and checked; if the check fails, the previous release comes back. Apps deployed with Noust 1.x, which keep no earlier releases, are checked and only report a failure.

How each kind of app is deployed

How an app sits on disk

Going back to #3 means pointing current at its directory again: a few seconds, nothing rebuilt.

The directory of wrenfield.io on the server: three releases, #4, #3 and #2, and current, a link that points at the live one, #4. noust releases rollback wrenfield.io moves current to #3, and #3 is live: nothing is rebuilt. Beside them, shared/.env, one file with mode 0600 for every release, and repo/, the git cache.

Noust puts code back, never a database

If a release ran a database migration, Noust asks you to confirm before going back past it, because the schema stays as the migration left it: the code goes back, the database does not.

Rolling back

Certificates, domains, databases, backups, alerts and logs, beside your apps

One console for what is usually spread across certbot, a backup script, a monitoring service and a database client.

Alerts before your client calls

Set a limit on disk, memory, errors or response time. When a server stays past it, Noust tells you on Slack, by email or on 11 other channels, and again when it clears.

Certificates that renew themselves, and tell you when they can’t

Let’s Encrypt for every domain, renewed with 30 days to go. If one gets within 14 days of expiring, you get an alert.

A domain, from its DNS record to HTTPS

With your DNS provider connected, adding a name creates its record. Noust checks it from public resolvers, sets up the web server and adds the name to the certificate, without restarting the app.

A backup every night, off the server

The app, its .env and its databases, encrypted and sent to S3, R2, Backblaze or SFTP. It keeps the newest seven, and every 30 days it restores one as a test.

Find an error across every app and server

One search over the logs of every app and the system journal, on every server of the fleet. Passwords and tokens are masked before a line is shown.

Databases in the version you need

Keep your server’s PostgreSQL 16 and run 17 beside it, from the official image pinned by digest, listening only on 127.0.0.1.

206 apps that install with one command

Nextcloud, Immich, Grafana, Vaultwarden and 202 more. Each recipe pins the exact version of its images. 199 of them were started on a clean server on 28 and 29 Oct 2026 and passed their health check; 7 are still waiting for that test.

All apps

  • 217 in all

    Search them above, or open the full catalogue.

    Open the catalogue

Nextcloud

Files. Tested on 28 Oct 2026: the whole run, image download included, took 104 s.

noust recipe install nextcloud -d nextcloud.example.com

One console for all your servers

One Noust, the central, drives the others over SSH tunnels it opens itself. It never gets a shell on them, and each server sets how much the central may do.

  • The central never gets a shell

    Its key can forward one port and nothing else: the forced command is /usr/bin/false, set both in sshd and on the key.

  • Each server sets a ceiling for the central

    Read, deploy or admin, chosen on the server with noust fleet authorize and enforced there.

  • A changed host key stops the tunnel

    Each server’s key is recorded when you add it. If it ever changes, the tunnel closes and says why.

An animation of the sample fleet. fra-1, the central, opens an SSH tunnel to each of ams-3, lon-2 and mad-1; ams-3 lets it administer, lon-2 and mad-1 only deploy. The central sends an update to all three. palenbrook.io on ams-3 and quillfield.io on mad-1 pass their health checks and go live; on lon-2, release #14 of staging.wrenfield.io fails its check and #13 keeps serving. The renewed certificate of quillfield.io on mad-1, a backup sent from lon-2 and a disk alert at 91% on ams-3 all reach the console on fra-1. Then mad-1 stops answering and its tunnel closes; the central opens it again and mad-1 answers.

Two people for anything root, and a record nobody can quietly rewrite

Roles decide who can do what. Turn on approvals and anything that amounts to root waits for a second person. Every change goes into an audit log chained line by line and copied off the server.

An animation of an approval and the audit log on fra-1. Marta, an admin, asks for a root shell on fra-1, and the request waits for a second person. Sara, from security, approves it, and the shell opens. Each step is written to the audit log of fra-1, every line chained to the one before by its HMAC, and each line is copied to the SIEM, off the server, as it is written. Then, in that root shell, Marta rewrites line 62 of the log with sed so that it names sara instead of her. Sara runs noust audit verify: it checks the chain from the top, passes the lines before 62 and stops at line 62, which was changed after it was written. The copy of line 62 in the SIEM, off the server, still says marta.
  1. Root waits for a second person

    A root shell, a hand-written unit or nginx file, a deploy hook or a new role waits until someone from security approves it, and that someone is never the person who asked.

    tests/test_approvals.py
  2. An edited line is caught

    Each line carries an HMAC of the one before, so noust audit verify finds the first line that was changed.

    tests/test_audit_chain.py
  3. The copy off the server is the proof

    Root on the server holds the key and could rebuild a consistent chain. The copy Noust sends to syslog or your SIEM as each line is written is out of its reach, and still says what happened.

    tests/test_audit_shipping.py

New apps never build as root

Installing and building run as noust-build in a systemd sandbox. If Noust cannot prove the sandbox holds, the build stops instead of falling back to root. Building an app as root is a decision on record and, with approvals on, takes a second person.

Reaches: releases/#5, its build cache, the variables of its .env. Cannot see: /root, /etc/noust, other apps, Noust’s database.

tests/test_build_sandbox.py
  • Roles you can edit

    One person can hold several roles, on a team, a project or the whole server. Only an owner can make someone else an owner.

    tests/test_account_roles.py
  • A team sees only its own

    Another team’s app answers 404, exactly like one that does not exist. The check is made in the data layer, not route by route.

    tests/test_scope_architecture.py
  • Spain’s ENS, medium category

    One setting applies the measures a tool like Noust can enforce, and a report gives the auditor the evidence. Noust is not a certified system.

    tests/test_ens_profile.py

Check what you install

Every release has a signed git tag, and the installer publishes a signed SHA256SUMS. The Python packages of any commit rebuild identical, byte for byte. Verify a release

Report a vulnerability privately

Open a private advisory on GitHub, or email support@noust.dev with [noust security] in the subject. We confirm receipt within 3 working days and agree on a severity within 10. Open a private advisory

Anything the console does, you can script

The console is a client of the same JSON API your scripts call, and each page shows the equivalent command.

# build #5 beside #4, check it, switch
noust update wrenfield.io

# every release on disk, the live one marked
noust releases list wrenfield.io

# point current at the previous release, in seconds
noust releases rollback wrenfield.io

# the app’s journal, credentials masked
noust logs wrenfield.io --follow

# a recipe, health-checked like any app
noust recipe install immich -d photos.kelmoor.dev

One command per action, with the names the console uses. Every command

How Noust compares with the platforms you know

Seven platforms, the same questions. Every answer has its source.

Compare with
Self-hosted
Server manager
Hosted
  • Yes
  • Partly, or on a paid plan
  • No
  • Doesn’t apply, or not documented

Select an answer to see where it comes from.

Noust and seven other platforms, question by question
Self-hostedServer managerHosted
Question Noust CoolifyDokployDokkuLaravel ForgeVercelRailwayRender
Deploying
Checked before it takes traffic
Rolls back without rebuilding
Builds run isolated
Servers and people
Reaches other servers without root
Audit log included
Single sign-on included
Teams and roles included
Cost and lock-in
To start
Apps keep running if you leave

We read each platform’s own documentation, pricing and code on 29 Oct 2026, and Noust’s answers come from its documentation for 4.1. If something has changed, tell us in an issue.

Free and open source, with every feature

Everything Noust does is in the free version, single sign-on and the audit log included.

Community

€0

AGPL-3.0, and every release stays under it

  • Every feature: the fleet, SSO, SCIM, roles, the audit log and the ENS profile
  • As many servers and apps as you like
  • Signed packages, and updates through apt, dnf or zypper
  • Community support in GitHub issues
Install Noust

Enterprise

36 days

Arrives on .

Built on Community, one stone a day.

What people ask before installing it

Short answers. Each one links to the full explanation.

Can I use it on a server that already runs my apps?

Yes, without rebuilding them. noust app discover shows the nginx and Apache sites Noust did not write, and adopting one puts it in the console with its state, logs and restarts. A Compose stack is adopted as it runs, with noust app adopt. An adopted site has no deployments yet, so there is nothing to roll back until you deploy it from its source.

More: Adopting sites that already run

Does it run as root?

The service does: it installs packages and writes nginx, systemd and certificate files. For new apps, builds, installs and deploy hooks run as noust-build, an account without privileges, in a systemd sandbox, and each app runs as an account of its own.

More: Builds in the sandbox

Does a rollback undo database changes?

No. Noust puts the code back, never the database. A release that ran a migration asks you to confirm before you go back past it.

More: Rolling back

Do I need Docker?

Not for your own apps: Noust runs Node.js, Python, PHP, Go and static sites directly, as systemd services behind nginx or Apache. Docker is needed only for Compose stacks, container apps and most recipes.

More: First application

How big a server does it need, and what does it install?

To start, 1 GB of memory, 1 processor and 10 GB of free disk; 2 GB and 2 processors is comfortable, and below 512 MB of memory or 3 GB of disk the installer stops. It adds nginx, certbot, git and Node.js. Idle, Noust itself uses about 290 MB of memory: the console and the monitor, measured on Ubuntu 24.04.

More: Requirements

What happens to my apps if I stop using Noust?

They keep running. Each one is a systemd unit, an nginx or Apache site, a directory and a .env file, and systemctl, journalctl and git are enough to run them without Noust.

More: Leaving Noust

Does it send anything home?

No. There is no telemetry. The only request Noust makes on its own is the update check. The other side sees your server’s IP address and nothing else. noust config set updates.check false turns it off.

More: Privacy

Can I put the console on the internet?

Yes: noust console expose gives it a name, a certificate and nginx in front. It refuses while any account can sign in without a second factor.

More: Securing the console

What does the AGPL mean for my own apps?

Nothing. The AGPL covers Noust itself, not the apps it deploys: they keep their own licence, open or proprietary.

More: The licence

Try it on one server

One command on a fresh server. If Noust is not for you, your apps keep running without it.

curl -fsSL https://noust.dev/install.sh | sh

Run it as root on a fresh server: it installs nginx, certbot, git and Node.js. Check the script first.