# Deployment Strategies for no-mistakes: Managed Service, Binary Install, and Container Deployment

> Explore no-mistakes deployment strategies: managed-service, binary install, and container deployment. Ensure seamless operation across macOS, Linux, and Windows with automatic fallback.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: how-to-guide
- Published: 2026-07-11

---

**No-mistakes supports four primary deployment strategies: managed-service daemon (default), detached daemon fallback, binary-only installation, and self-update flow, with automatic fallback ensuring seamless operation across macOS, Linux, and Windows.**

The `no-mistakes` CLI tool from the [kunchenguid/no-mistakes](https://github.com/kunchenguid/no-mistakes) repository provides flexible deployment strategies that adapt to different environments, from developer workstations to CI pipelines. Whether you need a persistent background service that survives reboots or a lightweight containerized setup, the tool automatically handles daemon lifecycle management through a combination of OS service managers and robust fallback mechanisms.

## Managed-Service Daemon (Default)

The default deployment strategy leverages the host operating system's native service manager to run the `no-mistakes` daemon as a background process. During installation, the tool creates a per-user service that automatically starts on boot and survives reboots.

- **macOS**: Creates a `launchd` agent (`~/Library/LaunchAgents/com.kunchenguid.no-mistakes.daemon.<suffix>.plist`)
- **Linux**: Installs a `systemd` user service
- **Windows**: Configures a Task Scheduler task

The service name is scoped by the `NM_HOME` directory to prevent collisions between different installations. When the service is available, `no-mistakes` refreshes the service definition and restarts the daemon through the OS service manager. This approach is ideal for typical desktop environments where the daemon should persist across sessions.

See the daemon concept documentation in [`docs/src/content/docs/concepts/daemon.md`](https://github.com/kunchenguid/no-mistakes/blob/main/docs/src/content/docs/concepts/daemon.md) for exact filename patterns and service specifications.

## Detached Daemon Fallback

If the managed service cannot be installed—such as in minimal containers, remote SSH sessions, or CI runners without `systemd` or `launchd` access—the CLI automatically falls back to a detached daemon strategy.

In this mode, the CLI spawns the daemon directly as a background process. A **singleton lock file** at `<NM_HOME>/daemon.lock` ensures only one daemon instance runs per `NM_HOME` directory. The lock implementation in [`internal/daemon/lock.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/lock.go) acquires an exclusive OS file lock before any daemon work begins, preventing duplicate instances even when multiple commands execute simultaneously.

This fallback is transparent to users; commands that require the daemon (`init`, `attach`, `rerun`, `update`) automatically attempt to ensure the managed service is running, and only start a detached daemon if the service approach fails.

## Binary-Only Installation Methods

You can obtain the `no-mistakes` binary through three distinct methods, each suited to different development workflows:

**One-liner script** (recommended for quick setup):

```bash
curl -fsSL https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/install.sh | sh

```

The script places the binary in `~/.no-mistakes/bin`, creates a symlink in `~/.local/bin` (or `/usr/local/bin`), and automatically starts the daemon via the appropriate service manager.

**Go install** (for Go-centric environments):

```bash
go install github.com/kunchenguid/no-mistakes/cmd/no-mistakes@latest

```

This method does not embed telemetry identifiers by default, keeping telemetry disabled unless explicitly configured via environment variables.

**Make install** (for reproducible builds):

```bash
make install

```

Uses the repository's Makefile to build and install the binary.

Refer to [`docs/src/content/docs/start-here/installation.md`](https://github.com/kunchenguid/no-mistakes/blob/main/docs/src/content/docs/start-here/installation.md) for detailed instructions on each method.

## Self-Update Flow

The `no-mistakes update` command provides a built-in deployment strategy for keeping the tool current without manual re-installation. The update process:

1. Fetches the latest release from the repository
2. Verifies the SHA-256 checksum
3. Replaces the running binary atomically
4. Restarts the daemon using the same strategy (managed service or detached) as the current installation

The update logic resides in [`internal/update/update.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/update/update.go) and prefers the managed-service path when available, falling back to the detached daemon if necessary. This ensures your deployment remains consistent with its original configuration while applying the latest security patches and features.

## Container and CI Deployment

For ephemeral environments like Docker containers or CI pipelines, `no-mistakes` supports manual daemon initiation without OS service dependencies:

```bash
no-mistakes daemon start

```

When run this way, the daemon inherits the current process environment and uses the detached fallback automatically. The CLI ensures the daemon is running before executing any command that requires it; if the daemon is not present, it automatically launches a detached instance.

This strategy is suitable for CI pipelines that need gated pushes but cannot rely on persistent services. The daemon manager in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) handles the decision between managed service and detached fallback, while the CLI reference in [`docs/src/content/docs/reference/cli.md`](https://github.com/kunchenguid/no-mistakes/blob/main/docs/src/content/docs/reference/cli.md) documents how each sub-command ensures daemon availability.

## Core Implementation Details

Several components ensure reliable deployment across all strategies:

**Singleton Lock Mechanism**: Before spawning, the daemon acquires an exclusive OS file lock via [`internal/daemon/lock.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/lock.go) to guarantee only one instance per `NM_HOME`.

**Environment Persistence**: When launched via managed service, the daemon's `PATH` and proxy variables are baked into the service definition at install time, ensuring they survive subsequent restarts. See [`docs/src/content/docs/reference/environment.md`](https://github.com/kunchenguid/no-mistakes/blob/main/docs/src/content/docs/reference/environment.md) for exact behavior.

**Graceful Degradation**: The daemon manager ([`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go)) implements transparent fallback logic, attempting managed service first, then detaching if unavailable.

## Summary

- **Managed-service daemon** is the default strategy, using `launchd`, `systemd`, or Task Scheduler for persistent background operation.
- **Detached daemon fallback** activates automatically in containers or restricted environments, protected by a singleton lock file at `<NM_HOME>/daemon.lock`.
- **Binary installation** supports one-liner scripts, `go install`, and `make install`, with the script handling automatic service creation.
- **Self-update flow** atomically replaces binaries while preserving daemon configuration via [`internal/update/update.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/update/update.go).
- **Container deployment** uses manual daemon start with automatic fallback, suitable for CI pipelines and ephemeral environments.

## Frequently Asked Questions

### How does no-mistakes ensure only one daemon runs per installation?

The tool implements a singleton lock mechanism in [`internal/daemon/lock.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/lock.go) that acquires an exclusive OS file lock on `<NM_HOME>/daemon.lock` before any daemon work begins. This guarantees only one daemon instance operates per `NM_HOME` directory, regardless of whether it runs as a managed service or detached process.

### Can I run no-mistakes without installing system services?

Yes. If the managed service cannot be created (common in containers or restricted SSH sessions), the CLI automatically falls back to a detached daemon. You can also manually start a detached daemon with `no-mistakes daemon start`, which is useful for CI pipelines and containerized environments where OS service managers are unavailable.

### What is the difference between installing via the one-liner script versus `go install`?

The one-liner script (`curl | sh`) places the binary in `~/.no-mistakes/bin`, creates a symlink in your PATH, and automatically configures the managed service daemon. In contrast, `go install` simply builds and places the binary in your Go bin directory without embedding telemetry identifiers or creating service definitions, resulting in telemetry being disabled by default unless you explicitly set environment variables.

### How does the update command preserve your deployment configuration?

The `no-mistakes update` command, implemented in [`internal/update/update.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/update/update.go), detects whether the current instance runs as a managed service or detached daemon. It preserves this strategy when restarting the daemon after the atomic binary replacement, ensuring that systems using `systemd` remain managed by `systemd`, while container deployments continue using the detached approach.