Not a user. A builder. Fork the kernel, own the stack, and make it yours.
Forge is an application-hosted kernel with pluggable capabilities. Modular and transparent by design. Everything lives in public repositories under the forge-kernel GitHub organization, and you're free to fork any part of it.
That freedom is the point. You can fork just the module set, just the blueprints, or the entire system — then run it, rebrand it, and evolve it however you want. Nothing about the kernel forces you to stay on the default stack.
To fully own and rebrand your stack, fork the pieces you care about. Each one is a separate, self-contained repository, so you only take what matters to you:
The minimal kernel core — the DI container, module loader, CLI, config manager, and bootstrap. This is the heart; fork it to change how the Kernel itself behaves.
Maps module names to GitHub URLs. The package manager and installer use it to locate things to download.
Pre-assemblies that bundle certain capabilities so you can stand up an app quickly. Fork these to define your own starting templates.
All the optional capability modules — database, ORM, auth, storage, and the rest.
The bash script that bootstraps a new project from a blueprint.
The development monorepo that brings together the kernel, modules, installer, and docs. Fork this if you want to work on everything in one place.
There are a couple of optional ones too — the documentation site and forge-schemas (schema definitions for module manifests) — if you want to keep those in sync with your fork.
The package manager is a capability, not part of the Kernel itself. One of the things it manages is where your modules come from. It doesn't enforce anything — you explicitly add your trusted sources, the same way a Linux package manager works.
Sources live in config/source_list.php. This file isn't part of the Kernel's own config; the package manager creates it for you on first use, pre-filled with the official registry. Point it at your own registries and the package manager will search them in order when you ask to install something.
The package manager supports several source types, so you can keep your modules wherever makes sense for you:
GitHub, GitLab, Bitbucket, Azure DevOps, or self-hosted git repositories.
Secure file transfer over SSH.
Plain FTP, with optional SSL/TLS.
Direct URL downloads, with basic auth if you need it.
Plain directories on the local filesystem.
Network-mounted drives and SMB/CIFS shares.
A typical config/source_list.php might look like this — mixing a public git source, an internal SFTP box, and a local mirror:
<?php
return [
'registry' => [
[
'name' => 'your-org-modules',
'type' => 'git',
'url' => 'https://github.com/your-org/modules',
'branch' => 'main',
'private' => false,
'personal_token' => env('GITHUB_TOKEN')
],
[
'name' => 'internal-sftp',
'type' => 'sftp',
'host' => 'modules.internal.com',
'port' => 22,
'username' => env('SFTP_USER'),
'key_path' => env('SFTP_KEY_PATH'),
'base_path' => '/modules'
],
[
'name' => 'local-registry',
'type' => 'local',
'path' => '/var/modules-registry'
],
// Add more registries as needed.
// The package manager searches them in order.
],
'cache_ttl' => 3600
];Each source type has its own detailed configuration guide in the ForgePackageManager documentation, with dedicated pages for git, SFTP, FTP, HTTP, and local sources.
Like apt, yum, or pacman, the package manager won't install from a source you haven't explicitly trusted. When you install a module, you'll be prompted to trust the source it comes from.
Trusted sources are recorded in storage/framework/trusted_sources.json. That gives you complete control over what gets installed and from where — a source you haven't approved is simply never used.
Same philosophy, your rules. When you fork and point the package manager at your own registries, your users see the same prompt. You decide what's trusted and what isn't — the kernel doesn't override your choices.
In your fork of the installer repository, the script needs to know where your blueprints live. Open installer.sh and point BLUEPRINT_REPO_BASE_URL at your own blueprint archive:
BLUEPRINT_REPO_BASE_URL="https://github.com/your-org/forge-blueprint/archive/refs/heads/main.zip"That one constant is what tells a fresh install which blueprint to pull down — so changing it is the whole job of rebranding the installer.
Both the installer and the blueprint ship an install.php script — the one in the project root downloads the Kernel as a ZIP from your registry and unpacks it. Point that at your own registry by updating its FRAMEWORK_REPO_URL constant:
const FRAMEWORK_REPO_URL = 'https://github.com/your-org/framework-registry';Because install.php is a plain PHP file, you'll find the same constant in both places — the installer and the blueprint — so remember to update it in each fork.
Once your blueprint is forked, a few files keep it pointing at your stack instead of the default one:
config/source_list.php — point it at your registries, so anything the blueprint installs comes from you..env.example and composer.json — update names, authors, and any defaults that still say "Forge".A blueprint is just a starting skeleton. Once it's on disk it behaves like any normal app — the changes above just make the default experience yours.
If you want to go all the way, you can rename the Forge module prefix to something of your own. Because the kernel and its capabilities are plain PHP, this is mechanical rather than magical:
forge.json).This step is entirely optional. Some forks keep the Forge prefix and just rebrand the surfaces users see; others rename everything. Do what fits your goal.
After forking the repos that matter to you, updating the URLs, configuring your trusted sources, and optionally renaming the modules — you have your own kernel stack.
Fork it. Ship it. Evolve it however you want.
You're not a user. You're a builder.
Forge is MIT licensed. Take what helps. Ignore what doesn't.