My deployment platform is a shell script

What the deployment script does

• Several commenters restate the script’s behavior: poll git, pull/merge if there are new commits, build the Go binary, move it into place, restart the service.
• It’s recognized as intentionally minimal and tailored to a single-person, single-server workflow.

Appeal of simplicity and “little things”

• Many like the “limitations are good” philosophy: fewer moving parts, no external platforms, and tools (sh/ash/bash) that will likely work for decades.
• For personal projects, blogs, or small services, people report similar setups (shell + systemd/cron/ssh/rsync/docker-compose) that “just run” for years with almost no maintenance.
• This fits a broader trend some see back toward simplicity: monoliths, SQLite, direct VPS + bash instead of heavy orchestration.

Robustness, pitfalls, and nits

• Multiple comments critique the script’s use of ls for iteration and lack of strict error handling; they propose safer loops, globbing, subshells, directory stacks, and set -e-style patterns.
• Concerns include brittle behavior with spaces/newlines in filenames, running everything as root, unbounded logging, and cron-driven retries spamming logs if networking fails.
• ShellCheck, POSIX shell practices, and small refactors are suggested to make it safer without adding big tools.

Shell vs. Ansible / IaC / NixOS / others

• One side argues Ansible (and similar tools) better handle idempotency, logging, configuration files, multi-host fleets, and complex states; they see a playbook as a more maintainable “beaten path.”
• Others push back: for 1–a-few machines, Ansible/Puppet/etc. are viewed as slow, complex, and dependency-heavy compared to a 30-line script.
• NixOS is highlighted as an alternative where nixos-rebuild plus git effectively becomes the deployment loop, sometimes replacing Ansible entirely.
• Various alternatives are mentioned: GitHub Actions + Docker, webhooks + symlinks, plumbum (Python), Kamal, Deployer/Envoy, watchtower, Caddy-based setups.

Scale, reliability, and “serious” use

• Several note this pattern is fine for hobby or low-stakes services, but lacking for “serious” deployments: no crash recovery, zero-downtime rollout, load balancing, or secrets/DB management.
• Some mention organizational dynamics: simple custom scripts can be blamed on individuals, whereas failures in complex vendor-backed stacks diffuse responsibility.
• There’s consensus that context matters: keep small things small, but large/multi-host systems often justify more structured tooling.