Start with the
hard questions.

Forkalope is an open-source, GitHub-shaped code forge: repositories, issues, pull requests, automation, packages, permissions, and APIs in a familiar workflow. The larger idea is a cloud of independently operated nodes that can share authorized replicas and help one another recover when a primary home is unavailable. The forge comes first; the network has to earn its place through working software and tested operations.

Forgejo, Gitea, GitLab, and other projects already prove that self-hosted Git can work. Forkalope is exploring the layer they do not make central: portable identity and collaboration data, a visible relationship between node operators, and recovery between approved homes. That is a technical thesis, not a claim that Forkalope is more mature today.

The source and product direction are public, but the complete forge and shared recovery network are still in development. The current public build is this website. Follow the source repository for the first runnable slices, release notes, and the point at which a real demo is available. Until then, the site should not imply that a production forge or failover service already exists.

No. The planned network separates community nodes for mirrors, experiments, and learning; verified or anchor nodes that meet published checks for uptime, storage, backups, monitoring, and current software; and Forkalope core nodes operated for managed customers. A Raspberry Pi or home server can belong to the network without becoming a dependency for Acme’s production repositories.

An approved recovery partner would use an authorized replica and reserved capacity to restore service while the original operator repairs or rebuilds the failed node. A real recovery system must account for more than Git objects: permissions, issues, pull requests, packages, routing, authentication, and the latest confirmed write all matter. Forkalope should measure restore time and possible data loss in drills before offering automatic failover or an uptime guarantee.

A Tine is a proposed $30 monthly unit that helps fund shared servers, storage, backups, bandwidth, monitoring, and the people keeping the network healthy. It gives you a visible stewardship relationship to a logical node. Forkalope or an approved operator keeps the provider account and administrative keys, and sponsorship does not grant access to private customer data.

One Tine associates you with a node and its operator discussions. Two Tines support more capacity and give earlier access to network-building tools. Three Tines make you eligible to become the primary named steward of a logical node; that node can move from one server or provider to another while the stewardship relationship follows it. None of the tiers buys a physical server, equity, or a share of business revenue.

An Independent Sysop rents infrastructure in their own name, runs Forkalope, and takes responsibility for security, updates, capacity, backups, and incidents. An approved Sysop can coordinate Co-Sysops and participate in recovery under a separate operator agreement. This is an operating role with real duties, not a fourth membership tier or a reward for recruiting members.

Git repositories are already exceptionally portable. After ten years, Acme can still mirror the commits and push them to another Git server. The files and history are not the part we want to exaggerate.

The expensive part is everything built around those repositories: thousands of issues, pull requests, reviews, comments, labels, milestones, teams, permissions, branch protections, rulesets, Actions environments and secrets, runner configuration, packages, release artifacts, audit and security data, webhooks, GitHub Apps, OAuth integrations, SSO and SCIM mappings, and links from Slack, Jira, documentation, and internal tools. GitHub provides export and migration tooling, but a serious move still involves archives, APIs, mapping, validation, cleanup, and sometimes downtime. The result can be a new Git server with years of organizational context missing or rewritten.

Forkalope’s stronger goal is to make the complete development home portable. A customer should be able to export repositories and surrounding state in documented, open formats, or ask us to move the same Forkalope deployment to infrastructure the customer controls. That means the database schema, repository storage, configuration, integrations, and URLs have a documented handoff instead of becoming a one-off migration project.

Imagine Acme leaves after a decade. It provisions a server in its own Hetzner account, points its domain there, restores the Forkalope backup, verifies users and permissions, checks Actions and webhooks, and runs a cutover rehearsal. The software, data model, and workflows remain familiar. Forkalope may help with the handoff, but Acme owns the provider relationship and can keep operating without us.

If Acme eventually leaves Forkalope as a platform too, it can still take the portable route: mirror the Git data, export the collaboration and organization records, preserve artifacts and audit history where the destination supports them, and use the documented mappings to rebuild the remaining integrations. That will never make a decade-old migration effortless, but it should make the work inspectable and repeatable instead of proprietary archaeology.

Your Git repository is already portable. Forkalope aims to make the rest of your forge portable too. Switching hosting providers should not require switching platforms.

Our business pricing principle is simple: pay for the service and capacity your organization uses, not permission slips for each human. Adding developer 51 should not automatically create another line item. Teams should be able to add engineers, designers, contractors, bots, and occasional collaborators without stopping to calculate another seat.

That means our plan is to include unlimited members in business offerings. “Unlimited” does not mean unlimited infrastructure: storage, compute, bandwidth, CI minutes or concurrent runners, replica count, retention, regions, and support level all create real operating costs. Those are the boundaries we intend to publish and price around.

A larger organization may use more capacity, but its bill should grow because it needs more capacity or service—not simply because more people need an account. This is a pricing direction for the pilot, not a live rate card; early customers will help us set sustainable limits and prices before enrollment opens.