Skip to main content
Nerdit reconciles each service’s desired state. A running service is restarted after a crash according to its policy and backoff. degraded means a health check failed; it does not necessarily mean the container stopped.

​
Daily commands

Use doctor for machine-wide checks and diagnose for an application’s build phase, health, bindings, recent exit, logs, and suggested remediation. Read the error code and hint before changing settings.
stop changes desired state to stopped. restart changes it to running and clears backoff; it is also how to start a stopped service. Stopping the Engine alone does not mean its application containers have stopped.

​
Run a one-off command

Replace the command with one available in your image. It runs in a separate bounded container using the application’s image, environment, secrets, and volumes. It does not publish a new port or replace the service. Arguments after -- reach the image’s entrypoint without an added shell. Use an explicit sh -c for shell syntax. A Dockerfile ENTRYPOINT still applies. Never put credentials in command arguments: container inspection and the recorded last run can expose them. Prefer existing secret bindings. Diagnose an interrupted writer before repeating it; a failed command can already have changed data.

​
Persistent data and disk cleanup

Each deployed application receives /data, exposed as NERDIT_DATA_DIR. Data there survives restarts and redeploys. Data elsewhere in the container’s writable layer is disposable. Additional volumes use [deploy].volumes, for example uploads:/srv/uploads. Host paths are allocated by Nerdit; this is not arbitrary host-directory mounting. Back up ordinary application volumes separately because control-plane backup does not include them.
Inspect the proposed cleanup before nerdit gc. Configure retention deliberately. Source-only database dump accounting is also available in the disk API; older CLI tables do not show every newer category.

​
Remove an application

This removes the container and service record, and purges its secrets by default. Application data and images require explicit purge targets:
Data purge is irreversible. Make and verify an appropriate backup first. Active one-off commands, release commands, and resource dependents can prevent removal. --force can terminate work or break dependent applications; investigate the refusal instead of adding it automatically.
Managed databases have additional deletion requirements.

​
Troubleshoot by symptom

Use the troubleshooting guide for symptom-specific diagnostic steps and fixes. It covers connection failures, denied access, failed builds, unhealthy services, missing bindings, and HTTPS problems. On Linux, inspect journalctl -u nerdit.service or journalctl --user -u nerdit.service. Engine and Caddy logs live under the configured data directory; use the actual configured location, not another user’s home. When reporting a problem, include the Nerdit version, OS, command, error code, relevant redacted logs, and whether the failure is local or through the App. Remove tokens, credentials, private URLs, and application data. See support.