Infrastructure on StackOnward

Caddy vs Nginx vs Nginx Proxy Manager

Fri, 11 Sep 2026 05:15:00 +0800

Caddy vs Nginx is decided by where the reverse-proxy config lives and how certificates are renewed, not by a public request-per-second ranking. A small site with files in Git and default automatic HTTPS usually belongs on Caddy. Working Nginx configs, modules, or operator muscle stay on Nginx. A web UI for a handful of hosts is Nginx Proxy Manager, and that choice also means backing up an application, a database, and generated Nginx files.

Existing Nginx assets stay on the file path. A GUI path still needs a backup of the admin data.

Caddy vs Nginx is decided by the config source of truth

Axis	Caddy	Nginx	Nginx Proxy Manager
Daily config	Caddyfile or JSON	Nginx config files	Web admin UI
HTTPS	Certificate issue and renewal are default	Usually Certbot, acme.sh, or a cloud certificate	Common certificate actions in the UI
Git	Reviewed as files	Reviewed as files	Main state lives in a database
WebSocket	HTTP reverse proxy handles the usual upgrade	Upgrade-related headers must be set correctly	Follows the generated Nginx config
Cache and limits	Configurable	Mature and fine-grained	Bounded by the UI and Advanced config
Extra state	Config plus certificate storage	Config, certificates, and related scripts	App, database, certificates, and generated config

Files are easy to review and roll back. A database is easy to click through, and a restore has to cover that database together with the certificates.

Docker Compose Production: Images, Health Checks, Secrets

Fri, 11 Sep 2026 05:12:00 +0800

Docker Compose production on one host is a pinned image, durable data, a private app port, resource caps, and a stack that returns after a container or host restart. docker compose up -d only reports that the containers started.

The public internet should reach only the reverse proxy on 80/443. Keep the app port on loopback or on the container network.

When Docker Compose production is the right fit

Compose can run production when the whole stack lives on one machine, the service graph is small, and a host failure is recovered by a person or a script on another machine:

How to Configure Docker Volume Permissions and Secrets

Fri, 11 Sep 2026 05:12:00 +0800

How to configure Docker volume permissions starts with a numeric UID and GID match, not a matching username. Put database files and other container-generated state on a named volume, bind-mount host-managed config read-only, and grant each secret only to the service that reads it as a file. Recreate the container to prove the mount. Restore a backup in a separate environment to prove the backup.

Named volumes hold writable state. Bind mounts hold host-managed config. Secret files are granted per service.

Choose a named volume, bind mount, or tmpfs

Type	What belongs there	Why	Main risk
Named volume	Databases, queues, application state	Docker manages the lifecycle; the path is not tied to one host layout	Host backup and migration must name the volume and its driver
Bind mount	Caddyfile, explicit data directories, host scripts	The path is visible to existing backup and permission tools	The host path, owner, and SELinux or AppArmor labels all have to match
tmpfs	Short-lived sensitive files or fast scratch data that must not persist	Nothing is written to durable disk	A restart drops the files; the size counts against container memory

Docker storage(opens in a new tab) treats volumes(opens in a new tab) as the default for data a container generates. Bind mounts(opens in a new tab) are for files the host already owns. tmpfs(opens in a new tab) stays in host memory and is gone when the container stops. The image writable layer is the wrong place for runtime data: deleting the container deletes that layer.

How to Troubleshoot 502 and 504 Behind a Reverse Proxy

Fri, 11 Sep 2026 05:08:00 +0800

How to troubleshoot 502 and 504 starts at the hop that produced the status. Both codes come from a gateway or reverse proxy: 502 Bad Gateway means that hop did not get a usable response from upstream; 504 Gateway Timeout means it waited past its limit. Keep the headers, then reach the upstream from that hop’s network.

Connection refused, DNS failure, and an invalid response usually point to 502. An upstream wait past the proxy deadline usually points to 504.

How to troubleshoot 502 and 504 at the hop that returned the status

A browser may sit behind Cloudflare or another CDN, a cloud load balancer, and Caddy or Nginx. Save the status, headers, time, and request ID:

Automatic rollback for a failed deployment: transaction state, traffic switch, and rollback limits

Fri, 11 Sep 2026 05:00:00 +0800

Automatic rollback for a failed deployment is not docker compose down after the script dies. Recovery depends on three facts: whether the candidate already took public traffic, whether the previous upstream can still be restored, and whether business checks finished. If the previous version is still serving, stop only this candidate. If the traffic switch may be half-done, restore the previous upstream. If the new version is still in the observation window, switch back. Recovery should finish the commit records only when the release has already entered the commit phase.

Docker Compose Blue-Green: Health Check, Switch, Drain

Fri, 11 Sep 2026 05:00:00 +0800

A Docker Compose blue-green deployment on one server starts the candidate, waits until the app is ready, validates and switches the Caddy upstream, proves the public hostname, drains old connections, then stops the old version. Do not delete the old container before the candidate is taking traffic.

That sequence can shrink the unavailable window. The host, disk, Docker daemon, and shared database are still single points of failure, so measure the window instead of calling the result zero downtime.

The gateway switch is the only public cutover. Candidate startup and warmup happen before that switch.

Docker Compose blue-green only works under these constraints

Run two app instances on one host only when the service meets all of these conditions:

Why Pin a Docker Image Digest: Reproducible Deploys and Rollbacks

Fri, 11 Sep 2026 05:00:00 +0800

Pin a Docker image digest by writing the production image as repository:tag@sha256:digest. The version tag shows which release you planned. The digest is the content Docker must pull. latest, stable, or a movable version tag cannot guarantee that a rebuild or rollback returns the original image.

Pinning the index digest freezes the platform set. Each node still pulls the manifest that matches its architecture.

Why pin a Docker image digest instead of a moving tag

Docker’s image digest documentation(opens in a new tab) defines a digest as a SHA-256 identifier of image content. A registry maintainer can retarget the same tag to a patched image. The original digest does not move with the tag.

OneDev Tutorial: Docker Compose, Git, and CI/CD on One Server

Fri, 11 Sep 2026 04:24:00 +0800

A OneDev tutorial starts with one instance that can host Git, review, issues, CI/CD, artifacts, and packages. Keep code on a server you operate, and skip running a separate Git service, CI, and package registry, when that trade-off is worth the ops work. The official single-node baseline is also lower than full GitLab.

The environment is one 64-bit Linux host: OneDev and PostgreSQL run under Docker Compose, and Caddy terminates HTTPS. After the instance is ready, create a Go project and prove push, tests, image build, production deploy, backup, restore, and upgrade. A container in running is not enough. The repository, Git SSH, the pipeline, and restore still have to work.

How to Expose Docker Ports: 127.0.0.1, 0.0.0.0, Firewalls

Fri, 11 Sep 2026 04:14:00 +0800

How to expose Docker ports depends on the process listen address inside the container, the host publish bind, and the firewall or cloud security group in front of the host. Listening on 0.0.0.0 inside a container does not put that port on the public internet.

The app and database stay on the Docker network. The public internet reaches only the ports the proxy publishes.

How to expose Docker ports at each network layer

Where it is set	Example	What it means
App process listen	`0.0.0.0:8080`	Accept 8080 on every interface in this container
App process listen	`127.0.0.1:8080`	Accept 8080 only on this container’s loopback
Docker port publish	`127.0.0.1:8080:8080`	Host-local processes can reach container 8080 on host 8080
Docker port publish	`0.0.0.0:8080:8080`	Every IPv4 address on the host publishes 8080; the public internet may reach it
Compose internal access	`http://app:8080`	A peer on the same network uses the service name and the container port

The two uses of 0.0.0.0 are not the same action. Listening on every interface inside the container lets a proxy on the same Docker network connect. Publishing the port onto every host interface widens the host entry.

When to Run Database Migrations: Expand, Migrate, Contract

Fri, 11 Sep 2026 04:10:00 +0800

When to run database migrations depends on whether the current schema can serve both the old and the new application. Add compatible structure first, ship the new app, then backfill data. Drop columns, finish renames, and tighten constraints in a later release after the old version has left.

Destructive DDL is not tied to the first rollout of new code.

When to run database migrations depends on compatibility

The same DDL can wait on a lock for seconds or for minutes depending on table size, PostgreSQL major version, and live writes. Confirm those facts, plus how old and new code touch the table, before choosing a stage.