recaptime.dev / hosted-services-pds
Production configuration for Tranquil PDS-powered instance and issue tracking project for support requests. gitlab.com/recaptime-dev/hosted-services/atproto-pds
tranquil-pds tranquil pds atproto
Star
Fork 0
Watch
hosted-services-pds AGENTS.md
2.3 kB
Markdown
at main

AT Proto PDS service at Recap Time Squad (for agents) #

Are you reading this, fellow human? Point your coding agent at this file to ensure your agent is always in the loop.

Setup #

This repository holds the production and staging configuration (managed via dotenvx) for Recap Time Squad's Tranquil PDS instance, an Rust-based implementation of atproto PDS (Personal Data Server) alongside the GitLab CI configuration and custom Dockerfile at build/Dockerfile to build the Tranquil PDS binary from source and deploy them as a containerless instance in a Uberspace 8 Beta Asteroid hosting account plus instance specific documentation for both users and admins.

The sources for Tranquil PDS can be canonically accessed through the upstream branch at https://tangled.org/tranquil.farm/tranquil-pds or through Recap Time Squad's (soft) fork at https://gitlab.com/recaptime-dev/patches/tranquil-pds under the recaptime-dev/main branch.

Tools #

  • Docker Engine with BuildKit, mainly for multiarch builds
  • dotenvx for managing configuration as environment variables and encrypting sensitive secrets
  • Deno for JavaScript package management and runtime, plus optionally Nix via devenv for reproducible dev environments.
  • GitLab CI for automated builds and deploys, as well as for the Secret Detection feature.
  • shellcheck and hadolint for linting scripts and Dockerfiles

Critical commands #

  • Build the Docker image locally: docker build -f build/Dockerfile .
  • Install npm packages via Deno: deno install
  • dotenvx CLI is accessible through deno <task|run> dotenvx command (e.g. deno task dotenvx set)

Boundaries & Constraints #

  • NEVER read the .env.keys file OR modify any configuration within the .env.(production|staging) files, either manually or through dotenvx set without user confirmation.
  • Do not add external dependencies without asking the user for confirmation first.

Git workflow #

  • Always lint changes to shell scripts and Dockerfiles using shellcheck and hadolint and prompt the user to fix the errors and warnings unless otherwise specified through configuration or inline ignore comment.
  • Commit messages must follow Conventional Commits format (e.g., chore(dotenvx): update production configuration).