feat: add deployment script and systemd service #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "0-deployment-script"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Changes
Systemd Service (
deploy/aptora-extensions.service)/opt/aptora-extensions/.envDeployment Script (
deploy/deploy.sh)Justfile Integration
deploy HOSTrecipe with dependency onbuild-backendjust deploy <hostname>Security
.env.productionto.gitignoreto prevent committing sensitive credentialsUsage
Changes Requested
User=aptora,Group=aptora,AmbientCapabilities=CAP_NET_BIND_SERVICE,NoNewPrivileges=yes, and add hardening likePrivateTmp=yes). Updatedeploy/aptora-extensions.serviceanddeploy/deploy.shto chown files to that user.deploy/deploy.sh: validate local artifacts before uploading, verify remote sudo early, make the file move atomic (use.new+mv), avoid recursive backups of the full directory (use tar or just back up binary + .env), and make health check not assumecurlis present (fallback or document requirement).Summary of Changes
deploy/aptora-extensions.servicesystemd unit (runs asrootcurrently).deploy/deploy.shscript to copy binary, environment, and unit file to server and start the service.deploy/rollback.shscript to restore/opt/aptora-extensionsfrom a backup.deployandrollbackrecipes tojustfile, and build rules for frontend/backend..env.productionto.gitignore.Overall Feedback
Negative: The current deployment runs the service as
rootand performs privileged operations as root on the remote host. This increases risk unnecessarily. The deploy script also assumes local artifacts and remote prerequisites (sudo,curl) exist and uses a full-directory recursive backup which may be heavy or unexpectedly include sensitive data.Positive: The scripts are well structured, use
set -euo pipefail, include a clear rollback path and helpful messages, and the justfile integration makes the workflow easy to run. These are solid foundations — with privilege hardening and a few robustness improvements this will be production-ready.Please address the requested changes and re-request review.
deploy/aptora-extensions.service: Do not run the service asroot.User=aptora) and create that user on the host.AmbientCapabilities=CAP_NET_BIND_SERVICEandNoNewPrivileges=yes.PrivateTmp=yes,ProtectSystem=full(optional but recommended).root:root, or document a strong justification for keepingUser=root.Please update the unit file and deployment steps accordingly. @Pertempto
deploy/deploy.sh: verification/health-check: handle missingcurland make remote check more robust.Actionable changes:
sudo systemctl is-active aptora-extensionsand prints statuscurland runcurl --fail --silentagainst the configurable health endpointcurlis missing, fall back toss -ltnp(ornetstat) to confirm a process is listening on :80 and printjournalctl -u aptora-extensions -n 50 --no-pagerfor diagnostics/health) and document default in README or scriptThis avoids false failures when
curlisn't present and provides clearer diagnostics on failure. @Pertemptodeploy/deploy.shanddeploy/rollback.sh: Local artifact checks and early remote sudo validationPlease add these checks before starting SSH/scp operations:
./aptora-extensionsbinary exists and is executable. Exit with clear error if missing../.env.productionexists. Exit with clear error if missing.sudoworks:ssh "$HOST" "sudo -n true"and provide a helpful error instructing the operator to enable passwordless sudo or run the script with a user that can sudo.These prevent mid-deploy surprises and make failures easier to diagnose. @Pertempto