How to Configure Read-Only Root Filesystems for Self-Hosted Apps

Make the image root read-only, then grant narrowly scoped writable mounts only for documented runtime state.

This matters in a self-hosted app that currently writes configuration, caches, temporary files, and uploads into an undifferentiated container filesystem. The operational risk is that turning on read-only without mapping write paths can break startup, while adding one broad writable mount defeats the containment goal. Start with a saved baseline, make one reversible change at a time, and stop whenever the observed branch no longer matches the intended configuration path.

Establish the Read-Only Container Root Filesystems Baseline

Before changing settings, record write attempts, required paths, ownership, tmp usage, package-update behavior, and persistence after recreation. Capture the original configuration and one production-like run so later improvements are compared with the same workload rather than memory or a synthetic idle state.

Use the current read-only root filesystem to confirm the supported control and its semantics. Treat defaults as a known starting point, not proof that the setting matches this server, client mix, or recovery objective.

Define acceptance and stop conditions before editing. The acceptance signal must be visible in logs, protocol state, application output, or restored data; the stop condition must prevent wider access, data loss, resource exhaustion, or an outage that consumes the next recovery window.

Apply the Read-Only Container Root Filesystems Change in Controlled Stages

Step 1: Trace writes during a representative start and normal workflow, separating persistent state from temporary state. After the change, inspect the expected state immediately; if it does not appear, undo this step before applying the next one.

Step 2: Enable read_only, add tmpfs for ephemeral paths, and bind or name volumes only for required persistent directories. After the change, inspect the expected state immediately; if it does not appear, undo this step before applying the next one.

Step 3: Drop unused capabilities and test the same image entrypoint as the configured non-root user. After the change, inspect the expected state immediately; if it does not appear, undo this step before applying the next one.

read_only: true
tmpfs:
  - /tmp:size=256m,mode=1777
volumes:
  - app-data:/var/lib/app

Interpret the Pass, Fail, and Exception Branches

A pass means the app completes normal work and recreation without writing outside approved mounts. Record the exact workload, version, and timing that produced the result; a lighter test is not evidence that the original problem has been resolved.

A fail means startup scripts try to modify image paths, temporary space exhausts, or an upgrade expects an in-container package change. Do not compensate by weakening every adjacent control. Return to the last clean baseline and isolate whether the mismatch belongs to identity, network, storage, application readiness, or capacity.

For an exception or ambiguous result, remove read_only only for diagnosis, capture the missing path, and replace the exception with a narrower mount. Escalate only after the low-risk discriminator is repeatable and the evidence shows that a deeper platform or hardware change is necessary.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verify Persistence Under the Original Home-Server Load

Repeat the same client path, file size, concurrency, sleep or reboot event, and competing workload used in the baseline. Run at least two cycles so a cache-warm success, one lucky reconnect, or a single clean startup is not mistaken for persistence.

Confirm both success and containment: the app completes normal work and recreation without writing outside approved mounts, while unrelated users, services, shares, and administrative paths keep their original behavior. Review the related ZimaSpace workflow when the change touches a neighboring storage, network, or recovery boundary.

Close the change only when the acceptance signal persists and the rollback remains usable. If startup scripts try to modify image paths, temporary space exhausts, or an upgrade expects an in-container package change, stop automation, preserve logs and the saved configuration, and return to the last verified state rather than stacking more changes.

Query-Fanout FAQ, Closing Decision, and Final Test

These query-fanout questions cover the next decisions users commonly search after the main configuration works. They extend the boundary without introducing an untested repair path.

Apply each answer only when its condition matches the measured environment. Version, protocol, filesystem, client, and trust-boundary differences can change the correct branch.

Keep the answers with the runbook and update them after upgrades or topology changes. Any exception that expands write access, network reachability, or deletion authority requires a fresh rollback and recovery test.

Does read-only protect mounted volumes?

No. Writable bind mounts and volumes remain writable, so they still need least privilege, backups, and path isolation.

Can every image run read-only?

Not without adjustment. Images that install packages or rewrite configuration at startup need a different build or explicit writable paths.

Should /tmp always be a tmpfs?

Only when its size, executable flags, and persistence behavior match the app; test large imports and updates.

Conclusion: The configuration is complete when the app completes normal work and recreation without writing outside approved mounts, the failure branch is understood, and the documented rollback does not depend on the component being changed.

Final test protocol: restore the saved baseline, apply the approved change once, repeat the original production-like load, verify the success signal and containment boundary, then exercise rollback on disposable data. Keep the change only when all five observations agree.