# Leaving Noust

Noust does not sit between your applications and the machine. An application it deployed is a
systemd unit, an nginx or Apache site, a directory and a `.env` file: ordinary things that go on
working when Noust is stopped, removed, or never installed again. This page says what those things
are, how to stop depending on Noust without stopping anything, and how to take Noust off the server
afterwards. Nothing here needs Noust to be running except the first step.

The test of this page is the one every other page of Noust keeps: after you follow it, `systemctl`,
`journalctl`, your web server and `git` are enough to run the server.

## Before you go

Keep a copy of what Noust knows that the server does not show:

```bash
noust list                                   # every application, so none is forgotten
noust app export shop.example.com -o shop.json            # its settings, domains, health check, cron, variables, mounts
noust app export shop.example.com --as-yaml -o noust.yaml  # the same as a file for the repository
noust backup create shop.example.com --include-databases   # the files, with the databases it uses
noust env show shop.example.com --unmask     # the variables in clear, once, to a place you trust
```

`app export` keeps secrets out unless you ask for `--with-secrets`. The `.env` is a plain file (see
below), so a copy of it is a copy of the variables. The audit log, the deployment history and the
metrics are in the store (`/var/lib/noust/noust.db`) and stay there; export them if you need them.

## What an application is, without Noust

| Part | Where it is | What Noust adds to it |
|---|---|---|
| The process | `/etc/systemd/system/<app>.service`: `ExecStart=`, `User=`, `WorkingDirectory=` and `EnvironmentFile=` | A first line `# Generated by Noust`. Applications from before 0.14.1 have a legacy prefix before the name, until their next deployment renames the unit. |
| The environment | `<app>/shared/.env` on the release layout, `<app>/.env` in place, mode 0600, loaded by `EnvironmentFile=-` | Nothing: it is read by systemd and by your application. |
| The code | `/var/www/apps/<app>/`: `releases/<id>/`, a `current` link to the active one, `shared/` for the `.env` and persistent paths, `repo/` as a git cache | Nothing but the layout. `current` is an ordinary symlink: `ln -sfn releases/<id> current` is a rollback. |
| The site | `/etc/nginx/sites-available/<domain>` and a link in `sites-enabled/` (Apache the same) | A first line `# Generated by Noust`. A site you wrote yourself is never touched. |
| The certificate | `/etc/letsencrypt/live/<domain>/`, renewed by certbot's own timer | Nothing. `certbot renew --dry-run` proves it renews without Noust. |
| Its account | `noust-app-<app>` (a system account, no home, no shell) for applications from 3.2 | Applications from before keep running as the shared service account. |
| Workers and copies | `<app>-<process>@.service`, `<app>-replica@.service`, run from `<app>/workers` | Same marker. |
| Blue/green | `<app>@.service` (instances `@blue`, `@green`) and the upstream file under `/etc/nginx/noust-upstreams/` | Same marker. The site `include`s the upstream file. |
| A Compose stack | The stack's own directory and `docker compose`; the unit only runs `docker compose up -d` | A unit with the marker. Containers do not know about Noust. |
| Scheduled tasks | `noust-cron-<name>.timer` and `.service` | They run the command you wrote, as the account you named. A command that is `noust ...` needs Noust installed. |
| Backups | `noust-backup-<domain>.timer`, archives under `/var/backups/noust/` | The archive is a tarball with a manifest; the timer calls `noust backup create`. |

Databases are the servers' own (PostgreSQL, MySQL, MariaDB, Redis, MongoDB) and keep their own
data directories and roles; the credentials Noust created are roles of those servers, and the
`DATABASE_URL` in an application's `.env` is the only trace of them. An engine Noust runs in a
container (`noust-db-*`) is a Compose project under `/var/lib/noust/` with its own data directory.

## Taking Noust out of the way

Noust's own units are what to stop. None of the application units depends on them.

```bash
systemctl disable --now noust-web noust-monitor noust-previews.timer
systemctl list-unit-files 'noust-*' --no-legend      # everything else Noust wrote
```

Read that list before you remove anything:

| Unit | What it is | What stopping it costs |
|---|---|---|
| `noust-web` | The console and the API | Nothing for the applications. |
| `noust-monitor` | The resource monitor, alerts, the process samples | No more alerts or history. |
| `noust-previews` | The timer that sweeps expired previews | Previews are no longer swept. |
| `noust-cron-*` | Your scheduled tasks | Keep them: they are plain timers. |
| `noust-backup-*` | Your backup schedules | Keep them only if `noust` stays installed. |
| `noust-db-*`, `noust-dbexpose-*` | Database engines in containers, and database ports opened on purpose | Keep them: the databases serve applications. |
| `noust-tunnel-*`, `noust-link-*` | The SSH tunnels of a fleet | Only a central or a node uses them. |
| `noust-security-checks`, `noust-network-maintenance`, `noust-storage-clean` | Periodic checks and cleaning | Safe to stop. |

Then, what changes in how you work:

- **Deploying** is yours again: `git pull` in `repo/`, build, `ln -sfn` the new release into
  `current`, `systemctl restart <app>`. The unit does not care who made the release.
- **Environment** changes are edits of the `.env` file and a restart. A reference such as
  `{{project.NAME}}` or `{{secret:vault/path}}` in the console is already resolved in the file; the
  text it came from lives only in the store.
- **Certificates** renew by certbot's timer. A name Noust issued through a DNS provider needs that
  provider's credentials in certbot's own configuration; check `certbot certificates`.
- **Backups** of the files are `tar` of the application directory and a dump of its databases.
- **Sandboxed builds** ran as `noust-build` in a transient unit; a build you run yourself is yours.

## Coming back

A site you stop managing, or one Noust never deployed, can be registered again without rebuilding it:
`noust app adopt-site` ([Adopting sites that already run](/docs/guides/adopting/)). Deleting an adopted site only
forgets it.

## Making the files yours

Every unit and site Noust writes starts with `# Generated by Noust`. That line is the only thing
that decides whether Noust may rewrite or delete the file. If you keep using Noust on the server
for some applications and want others left alone for good, delete the first line of their unit and
site and Noust treats them as yours: it never rewrites a site or unit without the marker (an update
says so and leaves the file). Removing the line from every file is also how you make a later
re-install of Noust leave the server's applications alone.

```bash
grep -l 'Generated by Noust' /etc/systemd/system/*.service /etc/nginx/sites-available/* 2>/dev/null
```

## Removing Noust

When nothing you kept needs the command any more:

```bash
apt remove noust        # or: dnf remove noust, zypper remove noust, pip uninstall noust
```

The package stops and disables the console and the monitor (`noust-web`, `noust-monitor`) and
touches nothing else: your applications, their units and sites, the configuration, the store and
the backups stay. `apt purge` goes one step further and removes `/etc/noust`, `/var/log/noust` and the
two unit files, and still leaves
`/var/www/apps` and `/var/lib/noust`. Everything below stays until you remove it yourself:

| Path | What it holds |
|---|---|
| `/etc/noust/` | The configuration, the console's secrets, deploy keys (mode 0600); gone after `apt purge` |
| `/var/lib/noust/` | The store (`noust.db`), the logs of deployments, runtimes |
| `/var/backups/noust/` | The backups |
| `/var/log/noust/` | Noust's own logs; gone after `apt purge` |
| `/opt/noust/runtimes/`, `/var/cache/noust/build/` | Pinned runtimes and the build cache |
| `/etc/nginx/noust-upstreams/` | The upstream files of blue/green and relayed services; sites that `include` them need them |
| `/etc/ssh/noust/`, `/etc/ssh/sshd_config.d/00-noust.conf` | Only on a server enrolled in a fleet or hardened from the console: the tunnel account's keys and the `Match User` block |
| `noust-app-*`, `noust-build`, `noust-tunnel` | The accounts (`userdel`), when no unit runs as them |
| `/etc/systemd/system/noust-*` | The units listed above that you chose to keep |

A server that came through 3.x may still carry links under the product's old names beside these
paths; `noust setup retire-links` removes the ones nothing uses, and `rm` removes any that is left.

## What a stopped Noust does

Nothing. Noust is not a daemon your applications call: it has no resident program in them and no proxy in front
of them. The requests it makes on its own are the update check (GitHub and the package repository;
`updates.check: false` turns it off) and the ones you configured (notifications, backup
destinations, a Git host); there is no telemetry or error reporting to anyone else. Its data is in
files you can read: the store is SQLite, the backups are tarballs with a manifest, the `.env` files
are the applications' own.
