FOSSBilling 개발 튜토리얼 2026: 자동화 산력 임대 플랫폼 구축

선행 결론: 먼저 분리, 그다음 선택

Whether provisioning is “automatic” does not depend on FOSSBilling vs WHMCS—it depends on whether payment events enter a reliable async provisioning pipeline.

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.