Key facts
| Inference layer | OpenAI-compatible /v1 API with 30+ models — no GPU operations |
| White-label option | Your brand, domain and colours on the dashboard and resale under your SKU |
| Isolation | Scoped keys and projects per tenant; region pinning per workspace |
| Metering | Per-request logs and per-key usage for tenant accounting |
| Model access | One endpoint covers chat, embeddings, RAG and function calling |
| Operations | Provider manages model upgrades, failover and capacity |
| Compliance posture | SOC 2 Type II and ISO 27001 readiness in progress (not yet certified) |
| Agreement | Commercial terms for resale live in the platform terms at /legal/terms |
TL;DR
- Your product is the platform; inference is a dependency, not a data centre.
- Own tenancy, onboarding, metering and support — those are the hard parts.
- Issue one scoped key per tenant and account for usage per key.
- Decide region strategy early: you inherit the provider's residency options.
- Read the resale terms before you publish pricing.
How it works, step by step
- Define the tenancy model: one project per customer with scoped keys and quotas.
- Build onboarding: account creation, plan selection and automatic key issuance.
- Wrap the API in your own gateway so tenant identity, guardrails and logging are consistent.
- Meter usage per key and store it for billing, quotas and analytics.
- Apply your brand to the surfaces customers see and keep provider branding out of the product.
- Add guardrails: PII policy, content rules, rate limits and spend caps per tenant.
- Review the provider terms for resale, branding and support responsibilities.
Try it yourself
Open the private LLM cost estimator →
What you build versus what you buy
Split the platform into layers and assign each one an owner:
- Buy from the provider: inference, embeddings, model upgrades, capacity, failover and the compliance baseline.
- Build in your platform: tenant model, signup and onboarding, key issuance, usage metering, billing, admin console and support workflows.
- Share: security controls. The provider supplies scoped keys, SSO and audit export; you enforce tenant-level authorization and PII policy in your gateway.
This is the same division of labour as building a SaaS on a cloud database: your differentiation is the product and the customer experience, not the compute.
Multi-tenant architecture on one API
A workable pattern is a thin gateway in front of Plugsky. Each tenant gets a project and a scoped key that your gateway holds — never the end customer. The gateway attaches tenant identity, applies rate limits and spend caps, redacts PII where required, logs for metering, and forwards to https://api.plugsky.com/v1. Because keys live server-side, rotation is invisible to customers. Pin a region per tenant when their data rules require it, and keep per-tenant logs so a billing question or a security review can be answered without guesswork.
Branding without claims risk
White-label means the customer sees your product, not your suppliers. Apply your domain, colours and language to the console and documentation; keep provider names out of customer-facing error messages. At the same time, do not over-claim: if your upstream certifies SOC 2 in progress rather than completed, your own compliance page must reflect the same reality, and your DPA should pass through the provider's data terms. Publish an accurate status and support policy, and read the resale and branding clauses in /legal/terms before launch.
The economics and the honest risks
Without GPUs, your cost base is the provider plan plus your engineering time, and your margin comes from packaging — seats, tiers, features — rather than from arbitraging token prices. The risks to manage are concentration (one provider outage is your outage), policy changes in upstream terms, and support boundaries when a model misbehaves. Mitigate with status monitoring, a documented incident process, region redundancy where the provider offers it, and a portable OpenAI-compatible core so a future provider change does not require a rewrite.
Honest comparison
| Layer | Build on Plugsky | Run your own GPU cluster | Build everything from scratch |
|---|---|---|---|
| Inference hardware | None | GPUs, networking, cooling | None at first, then heavy |
| Model operations | Provider-managed upgrades | Your MLOps team | You train and serve |
| Time to first customer | Weeks | Months | Quarters |
| Tenancy and metering | You build on scoped keys and logs | You build everything | You build everything |
| Residency options | Provider regions plus VPC/on-prem tiers | Your data centre location | Your choice |
| Cost structure | Flat plans plus your engineering | Capital plus operations | Capital plus operations |
Frequently asked questions
Do I need GPUs to launch an AI product?
No. An OpenAI-compatible provider supplies inference, model upgrades and capacity; your platform supplies tenancy, onboarding, metering and support. GPUs only become relevant if you need custom models or fully offline deployment.
Does Plugsky offer a white-label option?
Yes. The docs describe a white-label deployment with your brand, domain and colours so you can resell AI under your own SKU. Review the commercial terms at /legal/terms.
How do I isolate tenants?
Use one project and scoped key per tenant, held server-side by your gateway. Apply per-tenant rate limits, spend caps and logging, and pin regions where residency requires it.
How do I bill customers for AI usage?
Meter per request using platform logs and per-key usage. Self-serve provider plans are flat-rate, so you can package your offering by seats, tiers or quotas rather than passing through token costs.
What happens if the provider has an outage?
Failover routes around unhealthy upstreams, and the status page shows platform incidents. For stronger guarantees, design multi-region or private deployment options and document a degraded-mode experience for customers.
Can customers keep data in their own country?
Region pinning is available per workspace, and enterprise deployments extend to VPC, on-prem and air-gapped. Choose and verify the region during onboarding rather than retrofitting it later.
What compliance claims can I make?
Only what your own controls and the provider's evidence support. Plugsky documents SOC 2 Type II and ISO 27001 readiness in progress rather than completed certification, so pass through accurate status and avoid implying certifications you do not hold.
How much engineering does the platform need?
Plan for onboarding, key management, metering, guardrails and an admin console. The inference, scaling and model upgrades are handled upstream, which is the part that would otherwise require a platform engineering team.