DevWorkBase

Status: pre-Beta Date: 2 October 2026

DevWorkBase is a European-hosted, open-source collaboration platform for software teams.

Its purpose is to bring project management, source-code collaboration, documentation and CI/CD into one coherent environment, with one shared identity and organization model.

DevWorkBase does not aim to rebuild Jira, Bitbucket or Confluence from scratch. Instead, it integrates mature open-source products and adds the missing platform layer around them.

Core stack

Need	Component	Comparable Atlassian product
Project and work management	OpenProject 17.9	Jira
Git hosting and code review	Forgejo	Bitbucket
Knowledge and documentation	Wiki.js	Confluence
CI/CD	Forgejo Actions	Bitbucket Pipelines
Identity and organizations	Keycloak + DevWorkBase portal	Atlassian account / organization layer

DevWorkBase owns organizations, memberships, roles, groups, logical projects, lifecycle, provisioning state, application bindings, cross-application navigation, and integration metadata. The native applications keep their own data and permissions.

Single sign-on runs through Keycloak (OIDC everywhere); central logout terminates Portal, OpenProject, Forgejo, Wiki.js and the Account Console via RP-initiated logout and backchannel notifications.

Repository layout

Path	Content
apps/portal	DevWorkBase portal (Laravel + Inertia/React)
infrastructure/compose	Compose topologies (dev, prod, test, standalone runner), realm bootstrap
integrations/	Keycloak theme, OpenProject theme/OIDC plugins, Forgejo theme + RP-logout, Wiki.js theme/broker module, Actions runner
scripts/	release.py release automation + test_release.py regression suite
docs/	Product/architecture documentation

Repository boundary

This public repository contains the DevWorkBase application, integrations, generic deployment definitions, health contracts and release tooling. The hosted environment's private topology, credentials, internal endpoints, deployment identifiers, monitoring implementation and operator runbooks live in the separate private developing4all/devworkbase-ops repository. Do not commit environment-specific values here.

Local development

cd infrastructure/compose
cp .env.example .env   # secrets are generated by up.sh on first run
./up.sh

Local hosts: devworkbase.test, work|code|docs|id.devworkbase.test (Traefik on 443; add the hosts to /etc/hosts pointing at your Docker host).

Release

python3 scripts/release.py candidate --version v0.1.0 --deploy runs the full gate — shell syntax, compose validation, release regression tests, theme tests, the full PHP suite, TypeScript, Vite build, Forgejo theme tests, the OpenProject plugin RSpec suite on a dedicated test image — then builds, smoke-tests, pushes immutable build<N> images plus v<M.m.p>-rc.<n> alias tags, and deploys to staging through Coolify with convergence verification. accept records staging acceptance — it refuses a never-staged candidate unless --no-staging is given explicitly (the waiver is persisted). promote aliases the accepted digests to a stable v<M.m.p> without rebuilding; the --skip-acceptance bypass requires a --reason that is audited in the stable manifest. validate is the test-only gate — same source/test checks, structurally no publish, tag, or deploy path. The legacy rc flow (YYYY-MM-DD-<sha>-rcN) remains supported and shares the same global number sequence. See docs/11-release-versioning.md. Staging only; production deployment is a separate explicit step.

Rollback: pin DEVWORKBASE_IMAGE_TAG to a previous immutable build/RC tag via deploy_staging in scripts/release.py and redeploy. No volume reset, no database rollback — migrations must stay backward/forward compatible.

Documentation

1. Vision and Product
2. Identity and Access
3. Platform and Integrations
4. Architecture and Hosting
5. Business and Funding
6. Roadmap
7. Research and References

The living work plan is ROADMAP.md. For reporting vulnerabilities see SECURITY.md.

Current project rule

Keep the documentation small. New documents should only be created when an existing document has genuinely become too large or represents a clearly separate deliverable.

Current open decisions

Settled by the prototype: identity provider (Keycloak, OIDC everywhere), tenancy model (shared single instances with DevWorkBase organization scoping), and the application domain layout (work|code|docs|id.<base>).

Still intentionally open:

• final licensing and commercial model;
• pricing;
• extent of the DevWorkBase portal UI;
• public vs. private Beta registration.

These decisions should be made through prototypes and validation rather than documentation alone.