Software forge
Forgejo runtime, configuration, Git access, email delivery and updates are operated reproducibly.
We design, migrate and operate Forgejo as a Git platform - including database, storage, Actions runners, identity integration, backups and clearly defined service levels.
The following are trademarks of their respective owners: Forgejo (the Forgejo project (domains held by Codeberg e.V.)). WZ-IT is an independent service provider and has no business, partnership, or contractual relationship with these companies. We offer independent migration, installation, hosting, and operations services.
Forgejo combines Git repositories, issues, pull requests, releases, Actions and package registries in a self-hostable platform. Source code can remain in a controlled environment without making development processes dependent on a public SaaS platform.
WZ-IT looks beyond the Forgejo container. We design the database, repository and LFS storage, SSH and HTTPS access, runner networks, identity, email delivery, monitoring, backups and recovery as one operating architecture.
We inventory repositories, organisations, access models, issues, pull requests, releases, packages, webhooks and CI dependencies, then plan the migration, test run and cutover.
Which metadata can be migrated automatically depends on the source platform and its API. Critical repositories can be protected during the transition through defined mirror or fallback paths.
Source code, access rights and build pipelines are business-critical assets. We combine Forgejo, its database, repository storage, Actions runners, identity and recovery into a documented operating platform.
Forgejo runtime, configuration, Git access, email delivery and updates are operated reproducibly.
Actions runners, images, network paths and secrets are separated from the web platform and segmented by risk.
Repositories, attachments, releases, LFS objects and packages are included in capacity and backup planning.
Monitoring, updates, backups, restore tests and incident processes protect the platform and development workflows.
We clearly separate platform operations, CI execution and business responsibility for repositories.
| Area | Responsibility | Scope and boundaries |
|---|---|---|
| Architecture and provisioning | WZ-IT | Target design, network, TLS, SSH, database, storage and reproducible deployment. |
| Forgejo runtime and updates | WZ-IT | Maintenance of the agreed instance including release assessment, backup and controlled updates. |
| Monitoring and backups | WZ-IT | Monitoring and backup of database, repositories, LFS, packages and relevant configuration. |
| Actions runners | Shared | WZ-IT operates agreed runners; images, permissions and allowed target systems are defined with development teams. |
| Organisations and permissions | Shared | WZ-IT implements the model; the customer names teams, owners and required business access. |
| Code, pipelines and releases | Customer | Source code, workflow logic, approvals and business quality remain with the responsible repository teams. |
| Migration and integrations | Optional WZ-IT service | Migrations, webhooks, deployment connections and custom automation are planned as a project scope. |
Manage repositories over SSH and HTTPS, branches, tags, releases, Git LFS, organisations and team structures centrally.
Use code reviews, issues, labels, milestones, projects and wikis to collaborate on software and documentation.
Run CI/CD workflows on separately operated runners. Runner networks, images, secrets and permissions are designed for the required risk profile.
Publish packages and OCI container images to integrated registries and distribute them through defined access rules.
Integrate LDAP or OAuth2/OIDC, teams, protected branches, tokens and repository permissions into a controlled access model.
Connect Forgejo to build, deployment and ticket systems through APIs and webhooks or mirror repositories to other platforms in a controlled way.
A clearly defined operating scope instead of an opaque hosting flat fee.
Compute, applications, storage and response are shown separately. You can see what ongoing operations include and which requirements need a technical assessment.
We also design custom Forgejo architectures, integrations and migrations. Contact us for a technical assessment.
One managed standard Forgejo application is included in the Starter workload. Every service level also includes flexible expert time for planned work during regular service hours. Select compute, additional applications, storage and the appropriate service level.
A workload is one compute instance with the applications agreed for it.
One standard app per workload is already included. Additional dedicated servers count as separate workloads.
€79.90 per started TB and month, including daily encrypted offsite backup with 7-day retention.
User count alone is insufficient. Repository size, Git LFS, packages, concurrent clones, Actions jobs and retention determine compute, storage and runner architecture.
| Usage scenario | Technical starting point | Key factors |
|---|---|---|
| Small internal development team without heavy CI jobs | S or M, PostgreSQL | Capacity also depends on repository, LFS and package volume. |
| Several teams using pull requests and packages | M or L, PostgreSQL, separate backup storage | Access peaks, search load and data growth are assessed in advance. |
| Forgejo Actions with build and deployment jobs | Separate runners per workload | Runner CPU, memory, cache and network access are sized independently of the Forgejo web server. |
| Business-critical forge with short recovery time | Custom architecture | Database, storage, runners, dependencies and recovery are designed against explicit RPO/RTO targets. |
Actions runners are separate execution environments. Their number, size and security boundaries are priced according to actual pipelines.
The standard price describes one managed workload. Runners, large repository storage, high availability and special network paths are added transparently.
Dedicated workload with agreed compute, backup, monitoring and service level.
Operation in the customer's account, for example when runners and target systems are already connected there.
Integration with existing virtualisation, storage, network and backup processes.
Forgejo and runners can be placed separately and connected through defined private links.
Forgejo exposes web, API and Git access and delegates workflows to runners. Entry points, tokens, repository protection and reachable target systems therefore need a joint design.
Browsers, Git clients, IDEs, APIs, webhooks and build or deployment targets.
TLS, SSH host keys, reverse proxy, firewall rules, rate limits and optional private access.
LDAP or OAuth2/OIDC, teams, tokens, protected branches and administrative emergency access.
Repositories, pull requests, issues, releases, Actions control and package registry.
Users, permissions, issues, configuration and other relational platform data.
Repositories, attachments, releases, LFS objects and registry content with suitable protection.
Separated execution environments with defined images, secrets, caches and network targets.
Before production launch, we document data paths, backup scope, runner trust boundaries and recovery of the complete chain.
Answers about licensing, migration, Actions, identity and operations.
Forgejo versions 9 and later are distributed under GPL v3 or later; versions up to and including 8 used the MIT licence. See the official Forgejo licence information for the authoritative status.
Yes. Git history can be transferred reliably. Issues, pull requests, releases, wikis, packages and permissions depend on the source platform, its API and the migration route and are verified in a test run.
Forgejo Actions uses a similar workflow model and can also read workflows from .github/workflows. Used actions, runner images, secrets and permissions still need testing; we do not promise universal compatibility.
Runners are designed as their own trust zone. We restrict network targets and permissions, define images and secrets and, where needed, separate projects or protection classes across runners.
Yes. Forgejo supports LDAP authentication sources and OAuth2/OpenID Connect connections. We configure attributes, groups, automatic registration and local emergency access according to the identity design.
The database, Git repositories, LFS objects, attachments, packages, configuration and secrets must be protected consistently. For distributed storage, we design the sequence and test recovery.
A resilient or redundant design is possible, but it must include database, storage, Git access, proxy and runners. We derive it from availability and recovery objectives rather than giving a generic HA promise.
Whether you run Forgejo in-house or need to host confidentiality-professional data §203-ready - we build, operate and maintain Forgejo on an encrypted on-site server. Data never leaves the building in cleartext.
See Forgejo on-premise
These solutions are often used together with Forgejo
These solutions offer similar functionalities and can be evaluated together
These solutions are direct alternatives with similar use cases
No risk: worst case, you leave with a clearer understanding of your project than before.


“WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.”
Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.
Timo Wevelsiep & Robin Zins
Managing Directors of WZ-IT
