pyinfra deployment implementations
Find a file
Michael Hanke ded7a225e9
Some checks failed
Codespell / Check for spelling errors (push) Failing after 23s
feat: make service unit template customizable
This pattern could be considered as a general approach across all
deployments.
2026-05-05 09:54:29 +02:00
.forgejo/workflows ci: codespell workflow added 2025-12-01 11:32:39 +01:00
deployments feat: forgejo(-aneksajo) deployment 2026-03-15 15:20:33 +01:00
liab_deployments feat: make service unit template customizable 2026-05-05 09:54:29 +02:00
tests chore: Python packaging and hatch project setup 2025-12-01 11:15:01 +01:00
.gitignore chore: Python packaging and hatch project setup 2025-12-01 11:15:01 +01:00
CONTRIBUTING.md doc: targeted parameter naming conventions 2025-12-04 08:59:32 +01:00
LICENSE.txt chore: Python packaging and hatch project setup 2025-12-01 11:15:01 +01:00
pyproject.toml fix: include actual package in wheel 2025-12-02 11:58:22 +01:00
README.md feat: forgejo(-aneksajo) deployment 2026-03-15 15:20:33 +01:00

Lab-in-a-box deployments

PyPI - Version PyPI - Python Version

This repository contains implementations of (standard) deployment workflows for machines and services. Implementations are done in Python using pyinfra.

Assumptions

This effort does not aim to serve every use case and deployment scenario. Instead, it makes a few central assumptions:

  • Users have access to an account on a target machine that allows for root-access via sudo.
  • The base OS on a target machine is Debian (12+), or a sufficiently close derivative. There is no hard dependency, but nothing else has seen significant use (yet).
  • Users have means to configure the DNS for a domain they want to use for exposing deployed services.
  • Caddy is used as a web-server/reverse-proxy.
  • Podman is used as a container solution.

See deployments/bootstrap_server_mih-style.py for a demo deployment that would set up a compatible base server.

Conventions

All provided deployment follow a common set of conventions:

  • One service, one user: Each deployment creates/uses a service-dedicated user account. All code runs in user-space.
  • Containerized environments: Code is generally deployed in virtual environments -- typically user-space podman containers, but uv-managed virtual environments for (small) Python packages.
  • Systemd: Services are managed via user-space systemd service units.
  • Subdomains: Services are assumed to be deployed using dedicated subdomains (service.example.org, rather than example.org/service).

Repository layout

liab_deployments/deploy/

Workflow implementations. For details on particular workflows, check the comments at the top of each file.

  • copyparty: copyparty all-in-wonder fileserver that works with everything and anything
  • dumpthings: Metadata API and database
  • forgejo: Forgejo(-aneksajo), but should also work with a plain Forgejo
  • forgejo_runner: Forgejo runner using the "offline registration" approach
  • gatus: Gatus
  • gitannex_staticwww: git-annex repo (with submodules) is served as static content via caddy
  • hedgedoc: HedgeDoc v1 site, using a sqlite database
  • ntfy: ntfy.sh pub-sub notification service
  • owntracks: OwnTracks
  • photoview: Photoview using a sqlite database

OLD

These are yet to be integrated

  • bootstrap_server_mih-style: example base setup on top of a minimal Debian installation
  • forgejo_aneksajo_users: create accounts in a Forgejo instance from information in a TSV table

License

This software is distributed under the terms of the MIT license.