Multi-tenant by account
Each client's site is an instance on their forge-control org — their apps, their content, their brand. One deployment serves every tenant; tenant zero is our own site.
Promotion Site — multi-tenant, themeable, modular
Clients create their own promotion site on their forge-control org — their apps, their blog, their deals — themed to their brand and extended with modules. It ships as one integrated package with the control plane, git, identity and the package registry, or à la carte as API + public packages for whatever stack you already run.
What you get
No page builder to learn on day one: your content path is the same sidecar → deploy pipeline the federation already runs, scoped to your org.
Each client's site is an instance on their forge-control org — their apps, their content, their brand. One deployment serves every tenant; tenant zero is our own site.
Tokens, fonts, logo and mode per tenant on the fleet-wide @blueforge/themes package. Change a token, restyle the site — no deploy, no fork of the code.
Hero, catalog, promotions, blog, pricing, newsletter — sections you switch on, order and configure per site. Data-selected, code-shipped: no runtime code loading, no plugin malware surface.
CMS, blog, DAM, newsletter, social and marketing apps plug in as progressive data sources — absent config hides the module, never an empty box.
One deal
The promotion site cannot run without the control plane, and the control plane needs identity and git. Packr carries the sidecar packages, fgit and the forge CLI your repos install. So that is how we sell it: everything integrated, one purchase.
The product
Your multi-tenant promotion site — themes, modules, catalog, blog and deals at client.blueforge.studio or your own domain.
Full package, one purchase
Every piece above, pre-wired. The catalog, themes, modules and registration pipeline work out of the box because the four dependencies are part of the deal — not a checklist for you.
See the plansBring your own stack
GitHub user? Existing CI? Your own IdP? The integration is HTTP and YAML: sidecar files in any repo, an org key from forge-auth, one register call. Take the public packages from packr and keep the rest of your stack.
Register deploys with POST /api/deployments, read the catalog at GET /api/products — from GitHub Actions, your own CI, or anything that can send an HTTP request.
Sidecar schemas, marketing-kit and the rest of @blueforge-studio/* from packr. Public packages work with public access — no tenancy required to build.
fgit for git, forge for the fleet. Both work against your account; neither requires adopting our hosting.
The control plane inside the package
Deploys, vault, DNS, routing and registration live in Mission Control. It is the piece the promotion site cannot run without, so here is exactly what you are getting.
Pricing
Start free on a personal org. Buy the bundle when you want the whole integrated system, or the API + components when your stack is already elsewhere. Platform-wide tiers live on /pricing.
A promotion site on your forge-auth personal org — create an account and claim client.blueforge.studio-style hosting on the shared zone.
No card. Personal org, upgradeable to a team org.
Recommended — full package
The promotion system as one integrated deal — everything below, wired together, one purchase. You cannot run the promotion site without the control plane, and it needs identity and git: so we sell it whole.
Concierge checkout — we wire the package to your org.
Already have GitHub, CI, even your own IdP? Buy just the API and the public packages — the integration works from whatever system you run — and add forge-* components one at a time later.
Pick components at checkout; GitHub and any CI work.
Platform-wide plans (Community → Enterprise) are rendered from plans.yml on /pricing.
Developers
Four steps from zero to a registered product. The same flow works whether your repo lives on forge-git or GitHub.
Sign up at forge-auth — a personal org is created for you and is the tenant key for everything that follows.
Create account →Two YAML files in your repo: blueforge.product.yml (identity, links, assets) and blueforge.features.yml (marketing copy, promotions). Same format whether your repo lives on forge-git or GitHub.
Sidecar standards →POST /api/v1/keys/org on forge-auth returns a key that resolve() maps to your organizationId — the credential your CI uses to register.
API reference →POST /api/deployments with the key. Your tenant's catalog, showcase and promotions update — no portal, works from any CI including GitHub Actions.
See the curl →curl -s https://blueforge.studio/api/products | jq '.products[:3]' # → your tenant's merged catalog: deploy facts + sidecar copy + imagery
curl -sX POST https://blueforge.studio/api/deployments \
-H "Authorization: Bearer $BLUEFORGE_ORG_KEY" \
-H "Content-Type: application/json" \
-d '{
"repo": "acme-store",
"app": "site",
"url": "https://acme.example.com",
"commit": "'"$(git rev-parse HEAD)"'",
"deployment_id": "'"$GITHUB_RUN_ID"'",
"product": { "id": "acme-store", "name": "Acme Store", ... },
"features": { "product": "acme-store", ... }
}'
# key → forge-auth resolve → organizationId → your tenant. Never the body.# from packr — public packages need only public access npx pacquet add -D @blueforge-studio/blueforge-sidecar-schemas # fgit — forge-git CLI forge — fleet / deploy CLI
Free on a personal org. The full package when you are ready to run the whole system.