FOSSBilling 開発チュートリアル 2026：自動算力レンタルプラットフォームの構築

結論：まず分離、次に選定

「自動開通」は FOSSBilling か WHMCS かではなく、支払いイベントが信頼できる非同期開通パイプラインに入るかで決まる。

To validate “someone will pay to rent a Mac”—FOSSBilling products + Stripe + manual provisioning can ship in a week. For 24/7 unattended, auditable inventory, and billable resize, split billing from orchestration. kvmboot runs FOSSBilling for portal and invoices, a BFF at api.<domain>, and DC APIs for allocation.

1. なぜ算力レンタルは「收款ページ」だけでは足りないか

First-time compute rental platform teams often copy Shopify: pretty landing + pay button = done. Compute is time-bounded consumable inventory—one M4 Mac mini cannot be sold twice as exclusive monthly dedicated; GPU VRAM at an instant caps how many inference jobs you accept.

• Manual provisioning: ops watches email, SSH creds sent by hand—scale caps at headcount.
• Billing welded to resources: hypervisor calls inside payment plugins—every FOSSBilling upgrade becomes full regression.
• No service state machine: portal shows “paid” only—no provisioning / active / suspended—ticket storm.
• Split identities: portal account, site signup, anonymous trial IDs never reconcile.

“Build fast” means use mature open billing to cut ~60% boilerplate, focus engineering on inventory and provisioning—the value of FOSSBilling development here, not replacing your DC control plane.

2. FOSSBilling が担う範囲（What）

FOSSBilling is an open WHMCS/Blesta alternative (PHP + MySQL, MIT). In automated compute rental, keep it on the “commercial contract” layer only:

2.1 Billing layer (FOSSBilling strength)

• Products and pricing: daily / weekly / monthly, tiers (16GB / 24GB / storage add-ons).
• Orders, invoices, coupons, tax display (region-dependent).
• Client portal portal.<domain>: billing history, tickets, partial service list.
• Payment adapters: Stripe, PayPal, custom aggregators.
• Cron: renewal reminders, overdue suspend hooks (must sync with downstream orchestration).

2.2 Business API layer (standalone BFF)

Modern lease sites use custom marketing frontends (i18n, SEO, comparison tables). Do not call FOSSBilling internal APIs from the browser—use a stable BFF (Node/Go) with clear OpenAPI, CDN cache, and unified x-client-ssaid / token auth for anonymous vs registered users.

2.3 Resource layer (Provisioner—you build this)

VM create, bare-metal Mac assign, volume attach, DNS, SSH/VNC delivery—Provisioner listens for paid / expiring / suspended events, calls DC APIs, writes back custom fields or BFF DB. Cloud Mac teams running Agent/CI can share tenant IDs with Runner profiles and tenant quotas.

3. 核心比較：WHMCS vs FOSSBilling vs 自研

Unified five-column headers—paste into architecture reviews.

For most compute rental platform startups, FOSSBilling is the sweet spot between WHMCS and scratch—ship MVP with payments and manual provisioning fallback in 4–8 weeks instead of 3–6 months on invoices alone.

4. 推奨アーキテクチャ：課金 + BFF + 開通

┌─────────────────────────────────────────────────────────────┐
│  Marketing frontend (static site + JS)                       │
│  Sign-up / checkout / console → BFF OpenAPI                  │
└───────────────────────────┬─────────────────────────────────┘
                            │ HTTPS  api.example.com
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  BFF (Node/Go): auth, aggregation, webhook ingress           │
│  · x-client-ssaid anonymous / x-client-token registered      │
│  · order queries, service list, provisioning status          │
└───────┬─────────────────────────────┬───────────────────────┘
        │                             │
        ▼                             ▼
┌──────────────────┐        ┌─────────────────────────────┐
│ FOSSBilling       │        │ Provisioner + queue (Redis)  │
│ portal.* billing  │        │ · paid → allocate compute    │
│ products/orders   │        │ · expiry → suspend / reclaim │
│ Stripe / Epay     │        │ · write back custom fields   │
└────────┬─────────┘        └──────────────┬──────────────┘
         │                                  │
         ▼                                  ▼
    MySQL + Redis                    DC API (Mac/KVM/GPU)

Reference deploy (kvmboot-shaped): docker compose for MariaDB, Redis, fossbilling/fossbilling, fossbilling-br BFF, Nginx. Split www (static), api (BFF), portal (admin + client). Run ./init.sh yourdomain.com, ./deploy.sh, ./after-init-patch.sh for unattended install (skip browser /install) and seed products.

Docs: FOSSBilling Docs, Stripe Webhooks. Trigger provisioning via webhook + idempotent queue—never rely on payment return URLs alone.

5. シナリオの選び方

6. 推奨スタック

MVP (~4 weeks):

init.sh → deploy.sh → after-init-patch.sh (auto FOSSBilling + products)
→ Stripe test mode → frontend via BFF → manual provisioning fallback

Unattended provisioning (8–12 weeks):

FOSSBilling SKU 1:1 with inventory pool
→ Stripe/Epay webhook → Redis queue → Provisioner
→ service active + Resend email + portal SSH/VNC

Cloud Mac + Agent (advanced):

Single tenant ID across FOSSBilling client, BFF, Runner quotas
→ daily PoC → monthly lock (see kvmboot plans)

7. 五つのよくある誤解

• Mistake 1: “FOSSBilling installed = platform done” — It is billing + clients only; without Provisioner you still run manual hosting.
• Mistake 2: “Put all provisioning in PHP modules” — Upgrade and test hell—provisioning must be async, retriable, observable.
• Mistake 3: “Frontend uses FOSSBilling guest login” — Use BFF OpenAPI login/register; guest endpoints are unstable for production.
• Mistake 4: “Payment return URL = provisioned” — Webhooks are source of truth; queue must be idempotent.
• Mistake 5: “Infinite inventory” — SKUs must map to physical/virtual pools—overselling bare-metal Mac breaks SLA.

8. 7 ステップ実装リスト

1. Lock SKUs and inventory model: e.g. “M4 16GB daily/monthly”, storage add-ons; state machine pending → active → suspended.
2. Bring up FOSSBilling stack: init.sh <domain> secrets; Resend/SMTP; deploy.sh compose.
3. Auto install and products: after-init-patch.sh; verify portal.<domain>/admin and imported catalog.
4. Wire payments: Stripe test keys + webhook to BFF; regional Epay PID/KEY in production.
5. BFF minimum APIs: Product list, create order, service status; x-client-ssaid for anonymous browse.
6. Provisioner v1: On paid message → assign host → write creds; failures to DLQ for manual fix.
7. Acceptance: E2E test SKU → SSH received → portal active → simulate suspend; then production payments.

9. FAQ

How large a compute rental platform can FOSSBilling support?

Hundreds of orders/day and dozens of SKUs—FOSSBilling + BFF is usually enough. Complex multi-tenant tax or 100+ heterogeneous plugins may need WHMCS Enterprise or partial scratch.

Must provisioning live inside FOSSBilling?

No. FOSSBilling owns orders, invoices, clients, payments; VM/SSH/storage belongs in Provisioner or BFF async workers.

Can FOSSBilling rent Mac mini cloud hosts?

Yes—configure products and cycles; Stripe or regional pay; backend DC API assigns bare metal and delivers creds via email/portal.

Biggest FOSSBilling weakness vs WHMCS?

Smaller plugin ecosystem and enterprise support; wins on MIT, self-host, zero license—great for vertical teams with engineers.

Do I need PHP skills?

Not for day-to-day ops; needed for payment adapters, themes, modules. Most innovation should live in BFF/Provisioner (Node/Go/Python)—keep PHP thin.

10. まとめ

FOSSBilling tutorials are not about memorizing APIs—they are about boundaries: billing solves contracts and money; provisioning solves time-to-SSH and reliability. FOSSBilling can compress launch from “six months on invoices” to “weeks to first payment”; moat is inventory, SLA, and vertical UX (Xcode / Agent on cloud Mac).

Suggested path: FOSSBilling MVP → BFF frontend → Provisioner automation → then i18n and complex billing. Customers remember how fast they can SSH after paying—not which framework name you picked.