KNEL/TSYSDevStack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

snapshot

Browse Source
This commit is contained in:
Charles N Wyble - admin
2025-10-28 19:57:51 -05:00
parent 9f17603c1e
commit 65b278e33f
27 changed files with 875 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
collab/CloudronStack/GitUrlList.txt Normal file
View File

@@ -0,0 +1,61 @@
https://github.com/target/goalert
https://github.com/tirrenotechnologies/tirreno
https://github.com/runmedev/runme
https://github.com/datahub-project/datahub
https://github.com/jhpyle/docassemble
https://github.com/pimcore/pimcore
https://github.com/kazhuravlev/database-gateway
https://github.com/adnanh/webhook
https://github.com/metrue/fx
https://github.com/fonoster/fonoster
https://github.com/oat-sa
https://github.com/rundeck/rundeck
https://github.com/juspay/hyperswitch
https://github.com/Payroll-Engine/PayrollEngine
https://github.com/openboxes/openboxes
https://github.com/nautechsystems/nautilus_trader
https://github.com/apache/apisix
https://github.com/gristlabs/grist-core
https://github.com/healthchecks/healthchecks
https://github.com/fleetdm/fleet
https://github.com/netbox-community/netbox
https://github.com/apache/seatunnel
https://github.com/rapiz1/rathole
https://github.com/wiredlush/easy-gate
https://github.com/huginn/huginn
https://github.com/consuldemocracy/consuldemocracy
https://github.com/BOINC/boinc
https://github.com/SchedMD/slurm
https://github.com/gophish/gophish
https://github.com/GemGeorge/SniperPhish
https://github.com/inventree/InvenTree
https://github.com/mendersoftware/mender
https://github.com/langfuse/langfuse
https://github.com/wireviz/wireviz-web
https://github.com/wireviz/WireViz
https://github.com/killbill/killbill
https://github.com/opulo-inc/autobom
https://github.com/midday-ai/midday
https://github.com/openblocks-dev/openblocks
https://github.com/jgraph/docker-drawio
https://github.com/SigNoz/signoz
https://github.com/getsentry/sentry
https://github.com/chirpstack/chirpstack
https://github.com/elabftw/elabftw
https://github.com/PLMore/PLMore
https://gitlab.com/librespacefoundation/satnogs
https://github.com/jamovi/jamovi
https://github.com/reviewboard/reviewboard
https://github.com/Resgrid/Core
https://github.com/f4exb/sdrangel
https://github.com/stephengpope/no-code-architects-toolkit
https://github.com/sebo-b/warp
https://github.com/windmill-labs/windmill
https://github.com/cortezaproject/corteza
https://github.com/mendersoftware
https://github.com/security-companion/security-awareness-training
https://github.com/strongdm/comply
https://github.com/todogroup/policies
https://github.com/sebo-b/warp
https://github.com/windmill-labs/windmill
https://github.com/HeyPuter/puter

76
collab/CloudronStack/README.md Normal file
View File

@@ -0,0 +1,76 @@
# Cloudron Packages for Knowne ELement Enterprises
This repository contains all of the Cloudron packaging artifacts for the following upstream projects:
## Monitoring & Observability
- https://github.com/getsentry/sentry
- https://github.com/healthchecks/healthchecks
- https://github.com/SigNoz/signoz
- https://github.com/target/goalert
## Security & Compliance
- https://github.com/fleetdm/fleet
- https://github.com/GemGeorge/SniperPhish
- https://github.com/gophish/gophish
- https://github.com/kazhuravlev/database-gateway
- https://github.com/security-companion/security-awareness-training
- https://github.com/strongdm/comply
- https://github.com/tirrenotechnologies/tirreno
- https://github.com/todogroup/policies
- https://github.com/wiredlush/easy-gate
## Developer Platforms & Automation
- https://github.com/adnanh/webhook
- https://github.com/huginn/huginn
- https://github.com/metrue/fx
- https://github.com/openblocks-dev/openblocks
- https://github.com/reviewboard/reviewboard
- https://github.com/runmedev/runme
- https://github.com/stephengpope/no-code-architects-toolkit
- https://github.com/windmill-labs/windmill
## Infrastructure & Operations
- https://github.com/apache/apisix
- https://github.com/fonoster/fonoster
- https://github.com/mendersoftware/mender
- https://github.com/netbox-community/netbox
- https://github.com/rapiz1/rathole
- https://github.com/rundeck/rundeck
- https://github.com/SchedMD/slurm
## Data & Analytics
- https://github.com/apache/seatunnel
- https://github.com/datahub-project/datahub
- https://github.com/gristlabs/grist-core
- https://github.com/jamovi/jamovi
- https://github.com/langfuse/langfuse
- https://github.com/nautechsystems/nautilus_trader
## Business & Productivity
- https://github.com/cortezaproject/corteza
- https://github.com/HeyPuter/puter
- https://github.com/inventree/InvenTree
- https://github.com/jgraph/docker-drawio
- https://github.com/jhpyle/docassemble
- https://github.com/juspay/hyperswitch
- https://github.com/killbill/killbill
- https://github.com/midday-ai/midday
- https://github.com/oat-sa/package-tao
- https://github.com/openboxes/openboxes
- https://github.com/Payroll-Engine/PayrollEngine
- https://github.com/pimcore/pimcore
- https://github.com/PLMore/PLMore
- https://github.com/sebo-b/warp
## Industry & Specialized Solutions
- https://github.com/BOINC/boinc
- https://github.com/chirpstack/chirpstack
- https://github.com/consuldemocracy/consuldemocracy
- https://github.com/elabftw/elabftw
- https://github.com/f4exb/sdrangel
- https://gitlab.com/librespacefoundation/satnogs
- https://github.com/opulo-inc/autobom
- https://github.com/Resgrid/Core
- https://github.com/wireviz/wireviz-web
- https://github.com/wireviz/WireViz

49
collab/SupportStack/BuildTheStack
View File

@@ -7,13 +7,21 @@ Create an out-of-the-box, localhost-bound only, ephemeral Docker volume-only dem
Create a proof of concept with docker-socket-proxy, homepage, and wakaapi components that demonstrate proper homepage integration via Docker Compose labels. This MVP will serve as a validation of the full approach before proceeding with the complete stack implementation.
## Architecture Requirements
- All Docker artifacts must be prefixed with `TSYSDevStack-SupportStack-Demo`
- All Docker artifacts must be prefixed with `tsysdevstack-supportstack-demo-`
- This includes containers, networks, volumes, and any other Docker artifacts
- Example: `tsysdevstack-supportstack-demo-homepage`, `tsysdevstack-supportstack-demo-network`, etc.
- Run exclusively on localhost (localhost binding only)
- Ephemeral volumes only (no persistent storage)
- Resource limits set for single-user demo capacity
- No external network access (localhost bound only)
- Components: docker-socket-proxy, portainer, homepage as foundational elements
- All artifacts must go into artifacts/SupportStack directory to keep the directory well organized and avoid cluttering the root directory
- Homepage container needs direct access to Docker socket for labels to auto-populate (not through proxy)
- Docker socket proxy is for other containers that need Docker access but don't require direct socket access
- Portainer can use docker-socket-proxy for read-only access, but homepage needs direct socket access
- All containers need proper UID/GID mapping for security
- Docker group GID must be mapped properly for containers using Docker socket
- Non-Docker socket using containers should use invoking UID/GID
## Development Methodology
- Strict Test Driven Development (TDD) process
@@ -29,13 +37,16 @@ Create a proof of concept with docker-socket-proxy, homepage, and wakaapi compon
## MVP Component Development Sequence (Test Run)
1. **MVP**: docker-socket-proxy, homepage, wakaapi (each must fully satisfy Definition of Done before proceeding)
- docker-socket-proxy: Enable Docker socket access for homepage integration
- homepage: Configure to access Docker socket and discover labeled containers
- docker-socket-proxy: Enable Docker socket access for containers that need it (not homepage)
- homepage: Configure to access Docker socket directly for automatic label discovery
- wakaapi: Integrate with homepage using proper labels
- All services must utilize Docker Compose labels to automatically show up in homepage
- Implement proper service discovery for homepage integration using gethomepage labels
- Ensure all components are properly labeled with homepage integration labels
- Implement proper startup ordering using depends_on with health checks
- Homepage container requires direct Docker socket access for automatic service discovery
- Docker socket proxy provides controlled access for other containers
- All containers must have proper UID/GID mapping for security
## Component Completion Validation
- Each component must pass health checks for 5 consecutive minutes before moving to the next
@@ -45,7 +56,7 @@ Create a proof of concept with docker-socket-proxy, homepage, and wakaapi compon
- Homepage must automatically detect and display all services with proper labels
- Specific validation checkpoints after each service deployment:
- docker-socket-proxy: Validate Docker socket access and network connectivity to Docker daemon
- homepage: Validate homepage starts and can connect to Docker socket proxy, verify UI is accessible
- homepage: Validate homepage starts and can connect to Docker socket directly, verify UI is accessible
- wakaapi: Validate service starts and can be integrated into homepage with proper labels
- Each service must be validated in homepage dashboard after integration
- Detailed homepage integration validation steps:
@@ -54,6 +65,9 @@ Create a proof of concept with docker-socket-proxy, homepage, and wakaapi compon
- Validate service URL in homepage correctly links to the service
- Verify service group assignment in homepage is correct
- Check that any configured widgets appear properly in homepage
- Homepage must automatically discover services via Docker labels without manual configuration
- Validate Docker socket connectivity for automatic service discovery
- Confirm homepage can access and display service status information
- Update STATUS.md with validation results for each component
## Technical Specifications
@@ -72,9 +86,9 @@ Create a proof of concept with docker-socket-proxy, homepage, and wakaapi compon
- docker-socket-proxy: Internal network only, no external ports exposed
- homepage: Port 4000 (localhost only) - configurable via environment variable
- wakaapi: Port 4001 (localhost only) - configurable via environment variable
- All environment variables must be pre-set in TSYSDevStack-SupportStack-Demo-Settings file (single settings file for simplicity in demo)
- All docker compose files (one per component) should be prefixed with: TSYSDevStack-SupportStack-Demo-DockerCompose-
- All docker compose files should use environment variables for everything (variables will be set in TSYSDevStack-SupportStack-Demo-Settings file)
- All environment variables must be pre-set in tsysdevstack-supportstack-demo-Settings file (single settings file for simplicity in demo)
- All docker compose files (one per component) should be prefixed with: tsysdevstack-supportstack-demo-DockerCompose-
- All docker compose files should use environment variables for everything (variables will be set in tsysdevstack-supportstack-demo-Settings file)
- Health checks must validate service readiness before proceeding with dependent components
- Health check endpoints must be accessible only from internal network
- Health check configurations must be parameterized via environment variables
@@ -89,11 +103,20 @@ Create a proof of concept with docker-socket-proxy, homepage, and wakaapi compon
- Implement security scanning during build process (for demo, secrets via environment variables are acceptable)
- Define network policies for internal communication only
- Use depends_on with health checks to ensure proper startup ordering of services
- Homepage container requires direct Docker socket access (not through proxy) for automatic label discovery
- Docker socket proxy provides controlled access for other containers that need Docker access
- Portainer can use docker-socket-proxy for read-only access
- All containers must have proper UID/GID mapping for security
- Docker group GID must be mapped for containers using Docker socket
- Homepage container must have Docker socket access for labels to auto-populate
## Stack Control
- All control of the stack should go into a script called TSYSDevStack-SupportStack-Demo-Control.sh
- All control of the stack should go into a script called tsysdevstack-supportstack-demo-Control.sh
- The script should take the following arguments: start/stop/uninstall/update/test
- Ensure script is executable and contains error handling
- Script must handle UID/GID mapping for non-Docker socket using containers
- Script must map host Docker GID to containers using Docker socket
- Script should warn about Docker socket access requirements for homepage
## Component Definition of Done
- All health checks pass consistently for each component
@@ -116,6 +139,16 @@ Create a proof of concept with docker-socket-proxy, homepage, and wakaapi compon
- Component properly labeled with homepage integration labels (homepage.group, homepage.name, homepage.icon, etc.)
- Container uses pinned image tags rather than 'latest'
- Services validate properly in homepage after integration
- Homepage container has direct Docker socket access for automatic service discovery
- Homepage automatically discovers and displays services with proper labels
- Homepage validates Docker socket connectivity and service discovery
- All homepage integration labels are properly applied and validated
- Services appear in homepage with correct grouping, naming, and icons
- Homepage container has direct Docker socket access for automatic label discovery
- Docker socket proxy provides access for other containers that need Docker access
- Proper UID/GID mapping implemented for all containers
- Docker group GID properly mapped for containers using Docker socket
- All warnings addressed and resolved during implementation
## Testing Requirements
- Unit tests for each component configuration

4
collab/SupportStack/CharlesThoughts Normal file
View File

@@ -0,0 +1,4 @@
THings to add in to SupportStack
MCP Server Manager of some kind (CLI? Web? BOth?)
SO many options exist right now

198
collab/SupportStack/ChatPrompt-RefineAndSuggest-SupportStack.txt
View File

@@ -36,75 +36,157 @@ Notes:
I have been focused on the operations and infrastructure of building my businesses.
Hence deployment of Cloudron and the services on it and moving data into it from various SAAS and legacy LAMP systems.
Now I am focusing on setting up my development environment. I have a Debian 12 VM . I am setting up a fully dockerized development environment.
I have been putting together a list of support services to run. This is meant to run locally on my workstation and be highly personal/customized.
Now I am focusing on setting up my development environment on a Debian 12 VM. Below is an organized, left-justified reference of the selected SupportStack services — software name links to the project website and the second column links to the repository (link text: repository).
So far I have selected:
Core utilities
| Icon | Software (website) | Repository |
|:---|:---|:---|
| 🐚 | [atuin](https://atuin.sh) | [repository](https://github.com/ellie/atuin) |
| 🧪 | [httpbin](https://httpbin.org) | [repository](https://github.com/postmanlabs/httpbin) |
| 📁 | [Dozzle](https://github.com/amir20/dozzle) | [repository](https://github.com/amir20/dozzle) |
| 🖥️ | [code-server](https://coder.com/code-server) | [repository](https://github.com/coder/code-server) |
| 📬 | [MailHog](https://mailhog.github.io/) | [repository](https://github.com/mailhog/MailHog) |
| 🧾 | [Adminer](https://www.adminer.org) | [repository](https://github.com/vrana/adminer) |
| 🧰 | [Portainer](https://www.portainer.io) | [repository](https://github.com/portainer/portainer) |
| 🔁 | [Watchtower](https://containrrr.dev/watchtower) | [repository](https://github.com/containrrr/watchtower) |
atuin
httpbin
Dozzle
code-server
wiremock
kroki
redoc
mailhog
archivebox
tubearchivst
toxiproxy
reactiveresume
wakaapi
atomic tracker
portainer
hoppscotch
Jaeger All In One
swagger-ui
webhook.site
Adminer
Watchtower
https://github.com/google/cadvisor
node-exporter (containerized and exporting host system metrics)
pumba
Loki
Promtail
OpenTelemetry Collector
Registry2
CoreDNS
step-ca
Unleash
OpenPolicyAgent
Cadence workflow engine
https://github.com/pact-foundation/pact_broker
API, docs and mocking
| Icon | Software (website) | Repository |
|:---|:---|:---|
| 🧩 | [wiremock](http://wiremock.org) | [repository](https://github.com/wiremock/wiremock) |
| 🔗 | [hoppscotch](https://hoppscotch.io) | [repository](https://github.com/hoppscotch/hoppscotch) |
| 🧾 | [swagger-ui](https://swagger.io/tools/swagger-ui/) | [repository](https://github.com/swagger-api/swagger-ui) |
| 📚 | [redoc](https://redoc.ly) | [repository](https://github.com/Redocly/redoc) |
| 🔔 | [webhook.site](https://webhook.site) | [repository](https://github.com/search?q=webhook.site) |
| 🧪 | [pact_broker](https://docs.pact.io/pact_broker) | [repository](https://github.com/pact-foundation/pact_broker) |
| 🧰 | [httpbin (reference)](https://httpbin.org) | [repository](https://github.com/postmanlabs/httpbin) |
Observability & tracing
| Icon | Software (website) | Repository |
|:---|:---|:---|
| 🔍 | [Jaeger All-In-One](https://www.jaegertracing.io) | [repository](https://github.com/jaegertracing/jaeger) |
| 📊 | [Loki](https://grafana.com/oss/loki/) | [repository](https://github.com/grafana/loki) |
| 📤 | [Promtail](https://grafana.com/docs/loki/latest/clients/promtail/) | [repository](https://github.com/grafana/loki) |
| 🧭 | [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) | [repository](https://github.com/open-telemetry/opentelemetry-collector) |
| 🧮 | [node-exporter (Prometheus)](https://prometheus.io/docs/guides/node-exporter/) | [repository](https://github.com/prometheus/node_exporter) |
| 📦 | [google/cadvisor](https://github.com/google/cadvisor) | [repository](https://github.com/google/cadvisor) |
Chaos, networking & proxies
| Icon | Software (website) | Repository |
|:---|:---|:---|
| 🌩️ | [toxiproxy](https://github.com/Shopify/toxiproxy) | [repository](https://github.com/Shopify/toxiproxy) |
| 🧨 | [pumba](https://github.com/alexei-led/pumba) | [repository](https://github.com/alexei-led/pumba) |
| 🧭 | [CoreDNS](https://coredns.io) | [repository](https://github.com/coredns/coredns) |
| 🔐 | [step-ca (smallstep)](https://smallstep.com/docs/step-ca/) | [repository](https://github.com/smallstep/certificates) |
Devops, CI/CD & registries
| Icon | Software (website) | Repository |
|:---|:---|:---|
| 📦 | [Registry (Distribution v2)](https://docs.docker.com/registry/) | [repository](https://github.com/distribution/distribution) |
| ⚙️ | [Core workflow: Cadence](https://cadenceworkflow.io) | [repository](https://github.com/uber/cadence) |
| 🧾 | [Unleash (feature flags)](https://www.getunleash.io) | [repository](https://github.com/Unleash/unleash) |
| 🛡️ | [OpenPolicyAgent](https://www.openpolicyagent.org) | [repository](https://github.com/open-policy-agent/opa) |
Rendering, diagrams & misc developer tools
| Icon | Software (website) | Repository |
|:---|:---|:---|
| 🖼️ | [Kroki](https://kroki.io) | [repository](https://github.com/yuzutech/kroki) |
| 🧭 | [Dozzle (logs)](https://github.com/amir20/dozzle) | [repository](https://github.com/amir20/dozzle) |
| 📚 | [ArchiveBox](https://archivebox.io) | [repository](https://github.com/ArchiveBox/ArchiveBox) |
| 🧩 | [Registry tools / misc searches] | [repository](https://github.com/search?q=registry2) |
Personal / community / uncertain (link targets go to GitHub search where official page/repo was ambiguous)
| Icon | Software (website / search) | Repository |
|:---|:---|:---|
| 🧭 | [reactiveresume (search)](https://github.com/search?q=reactive+resume) | [repository](https://github.com/search?q=reactive+resume) |
| 🎞️ | [tubearchivst (search)](https://github.com/search?q=tubearchivst) | [repository](https://github.com/search?q=tubearchivst) |
| ⏱️ | [atomic tracker (search)](https://github.com/search?q=atomic+tracker) | [repository](https://github.com/search?q=atomic+tracker) |
| 📈 | [wakaapi (search)](https://github.com/search?q=wakaapi) | [repository](https://github.com/search?q=wakaapi) |
Notes:
- Where an authoritative project website exists it is linked in the Software column; where a dedicated site was not apparent the link points to a curated GitHub page or a GitHub search (to avoid guessing official domains).
- Let me know if you want this exported as Markdown, HTML, or rendered into your Cloudron/Stack documentation format.
Overview
This SupportStack is the always-on, developer-shared utility layer for local work and personal use. It is separate from per-project stacks (which own their DBs and runtime dependencies)
and separate from the LifecycleStack (build/package/release tooling).
All of the docker artifacts must be prefixed with TSYSDevStack-SupportStack-Demo . A full unit and end to end test suite providing greater than 75% coverage with 100% of the tests │
passing is required. Test driven development process must be STRICTLY adhered to. This means that a test is written, the test is executed, the test fails, then the minimal amount of code is written to get the test to pass. Also │
since this stack has such a large number of components, I want the work to be done on one component at a time until it's fully working. The foundational elements of docker socket proxy , portainer, homepage should be done │
first. Resource limits should be set on the components sufficient for a single user demo.
Services here are intended to be stable, long-running, and reusable across projects.
Architecture & constraints
- Dev environment: Debian 12 VM with a devcontainer base + specialized containers. Each project ships an identical docker-compose.yml in dev and prod.
- Deployment model: 12‑factor principles. Per-project stateful services (databases, caches) live inside each project stack, not in SupportStack.
- LifecycleStack: build/package/release tooling (Trivy, credential management container, artifact signing, CI runners) lives in a separate stack.
- Cloud policy: no public cloud for local infrastructure (Hard NO). Cloud-targeted tools may exist only for cloud dev environments (run in the cloud).
- Networking/UI: access services by ports. No need for reverse proxies (Caddy/Traefik) in SupportStack; the homepage provides the unified entry point.
- Credentials: projects consume secrets from the creds container in LifecycleStack. Do NOT add a credential injector to SupportStack.
- Data ownership: SupportStack contains developer & personal services (MailHog, Atuin, personal analytics). Project production data and DBs are explicitly outside SupportStack.
Operational guidelines
- Use explicit ports and stable hostnames for each service to keep UX predictable.
- Pin container images (digest or specific semver) and include healthchecks.
- Limit resource usage per container (cpu/memory) to avoid noisy neighbors.
- Persist data to named volumes and schedule regular backups.
- Centralize logs and metrics (Prometheus + Grafana + Loki) and add basic alerting.
- Use network isolation where appropriate (bridge networks per stack) and document exposed ports.
- Use a single canonical docker-compose schema across dev and prod to reduce drift.
- Document service purpose, default ports, and admin credentials in a small README inside the SupportStack repo (no secrets in repo).
I use Tailscale across Cloudron, my dev vm, my laptop/iphone/ipad to securely access all my workstation hosted services.
Cloudron apps are 100% 2fa/SSO
Suggested additions to the SupportStack (with rationale)
- Local artifact/cache proxies
- apt/aptly or apt-cacher-ng — speed package installs and reduce external hits.
- npm/yarn registry proxy (Verdaccio) — speed front-end dependency installs.
- Backup & restore
- restic or Duplicity plus a scheduled job to back up named volumes (or push to MinIO).
- Object storage & S3 tooling
- MinIO (already listed) — ensure lifecycle for backups and dev S3 workloads.
- s3gateway tools / rclone GUI for manual data movement.
- Registry & image tooling
- Private Docker Registry (distribution v2) — already listed; consider adding simple GC and retention policies.
- Image vulnerability dashboard (registry + Trivy / Polaris integrations) — surface image risks (Trivy stays in LifecycleStack for scanning).
- Caching & fast storage
- Redis — local cache for dev apps and simple feature testing.
- memcached — lightweight alternative where needed.
- Dev UX tooling
- filebrowser or chevereto-like lightweight file manager — quick SFTP/HTTP access to files.
- code-server (already listed) — ensure secure defaults for dev access.
- Networking & secure access
- WireGuard or a local VPN appliance — secure remote developer access without exposing services publicly.
- CoreDNS (already listed) — DNS for local hostnames and service discovery.
- Observability & testing
- Blackbox exporter or Uptime Kuma (already listed) — external checks on service ports.
- Tempo or Jaeger (already listed) — distributed tracing for local microservice testing.
- Loki + Promtail (already listed) — central logs; ensure retention policies.
- Development mocks & API tooling
- Wiremock / Mock servers (already listed) — richer API contract testing.
- Postman/hoppscotch (already listed) — request building and collection testing.
- CI/CD helpers (lightweight)
- Local runner (small container to run builds/tests) that mirrors prod runner environment.
- Container image pruning tools / reclaimers for long-running dev VM.
- Misc useful tools
- Sentry (or a lightweight error aggregator) — collect local app exceptions during dev runs.
- ArchiveBox / Archive utilities (already listed) — reproducible web captures.
- A small SMTP relay for inbound testing (MailHog already present).
- A small DB admin (Adminer already listed) and optional pgAdmin if need richer DB tools.
- Optional: a minimal artifact repository (Nexus/Harbor) if storing compiled artifacts or OCI images beyond the simple registry.
I have a separate development stack that I am developing. It has a devcontainer base and then various specialized containers to extend it. Each project will ship with an identical docker compose file in dev and in prod (we don't have any other environments). We use 12 factor for everything.
I have a separate lifecycle (build/package/release) stack that I am developing. That is where things like Trivy will go.
We DO NOT use the public cloud. Hard NO. However we have some products which customers may deploy to the public cloud. So our dev environment will need public cloud tooling. Any cloud dev will happen in the cloud in a cloud dev environment. No local support needed.
Operational checklist to add to repo
- Compose file naming and versioning policy (same file for dev & prod).
- Port assignment table (avoid collisions).
- Volume & backup policy (what to snapshot and when).
- Upgrade policy and maintenance window for SupportStack.
- Quick restore steps for any critical service.
We DO NOT use the public cloud. Hard NO. However we have some products which customers may deploy to the public cloud. So our dev environment will need public cloud tooling. Any cloud dev will happen in the cloud in a cloud dev environment. No local support needed.
Short example priorities for next additions
1. Verdaccio (npm proxy) + apt-cacher-ng — speed & reproducible installs.
2. Restic backup container that snapshots SupportStack volumes to MinIO.
3. WireGuard for secure remote dev access.
4. Image pruning/cleanup job and clear registry retention policy.
5. Add Redis and a lightweight error aggregator (Sentry) for local dev testing.
I am fine with using ports to access all the services. No need for Caddy/Traefik. Homepage provides a nice unified entry point for good UI/UX/DX already.
I do not need a personal kanban/roadmap. That all lives in Redmine.
I have a local influxdb/grafana for my own data collection that isn't for my startup/projects/clients. Its for personal data like my Apple Health exports.
Each of my dev projects will use the creds container in the lifecycle stack. As such , I don't need cred injector in the support stack.
This expanded description is designed to be pasted along with the rest of the SupportStack file to prompt ideation from ChatGPT/CoPilot/Grok/Qwen.
A database and other dependencies would be setup per project. Not in the SupportStack. The SupportStack is an always running no matter what stack. Does that make sense? It's meant to be leveraged across projects (things like Mailhog and Atuin for example) as well as by the developer for their personal enjoyment/use (atomic tracker for example).
Do you have any ideas for what other things I could add to my list of services in the SupportStack?
We will have separate conversations about the LifecycleStack for build/package/release tooling
Use the suggestions list to generate additional service proposals, playbooks, and compose templates for each recommended service.

31
collab/ToolboxStack/TSYSDevStack-toolbox-prompt.md Normal file
View File

@@ -0,0 +1,31 @@
# TSYS Dev Stack Project - DevStack - Toolbox
This prompt file is the starting off point for the ToolboxStack category of the complete TSYSDevStack.
## Category Context
The TSYSDevStack consists of four categories:
- CloudronStack (Free/libre/open software packages that Known Element Enterprises has packaged up for Cloudron hosting)
- LifecycleStack (build/test/package/release tooling)
- SupportStack (always on tooling meant to run on developer workstations)
- ToolboxStack (devcontainer base and various functional area specific devcontainers).
## Introduction
## Artifact Naming
## Common Service Dependencies
## toolbox-base
- mise
- zsh / oh-my-zsh / completions /
-
## toolbox-gis
## toolbox-weather