Distributed foundations
Shared state, queued work, and containerized execution support the distributed design. Capacity is established through workload testing.
PRODUCT STATUS / 15 NOVEMBER 2026
Working software.
Visible progress.
TUHFFF is in active pre-release development and is used to build itself. This page separates observed operation from the validation needed for a particular deployment.
OBSERVED IN THE DEVELOPMENT ENVIRONMENT
Running beyond the workstation.
- Live k3s execution: the control plane coordinates agent work in Kubernetes Jobs.
- Claude-backed runs perform development and review work against the project’s Forgejo repository.
- Codex smoke runs are recorded in the development history; that evidence is narrower than validation of every role and workflow.
- The active installation uses Postgres, with live operational logs reaching the observability backend.
- The forge history includes reviewed and merged improvements to TUHFFF itself.
DESIGN & VALIDATION
Scale with evidence.
Operational resilience
Restart behavior, placement delays, provider limits, and recovery are active areas of validation and improvement.
Integration scope
Forgejo and Gitea are the starting point. Other forge, provider, and deployment combinations require their own evaluation.
Evaluate your intended setup.
Start with a defined change, named acceptance criteria, and the tools and infrastructure you intend to use. Review the result, the interventions needed, and the available usage records before expanding the workload.
Pre-release access, distribution, licensing, support, and service terms are agreed directly. This page is a dated development snapshot; it is not a live service-status dashboard.
START HERE
Bring the problem.
Let’s put it to work.
Start with a conversation about what you need and how you will know it worked.
Plan an evaluation