Deployment

Graine is delivered three ways: as the multi-tenant cloud we operate, as a dedicated instance of the same platform reserved to you, or on your own infrastructure with our control plane still handling funding and metering.

All three run the identical set of services and data stores. The platform is defined as one self-contained stack, so choosing a model changes who operates it, where your data is processed, and what your concurrency ceiling is — not which features you get.

Deployment models

Shared cloud

The multi-tenant platform at api.graine.ai. This is the shape that receives changes first, and everything described on this page runs there today.

What it gives you — the whole platform with no infrastructure to operate, no egress to arrange and no capacity to provision. Concurrency, retention and rate limits are per-organization settings that can be raised for your account within a minute, without a release.

Tenancy is enforced in the application rather than by deployment: your organization is resolved from the authenticating API key and nothing else, every primary read carries the organization as a query term, and an identifier belonging to another tenant answers 404 rather than 403 so existence cannot be probed. The mechanism is described in Security.

Fixed regions apply:

There is no per-tenant region pinning on the shared cloud. If residency in a single jurisdiction is a requirement, one of the two models below is the answer.

Dedicated instance

The same platform — every service and every data store — deployed to infrastructure that serves only you, operated by us. Nothing about the software changes; what changes is that the compute, the databases, the object storage and the concurrency ceiling are yours alone, and the region is chosen at deployment rather than inherited.

What it gives you

• Single-jurisdiction processing, including recordings and transcripts.
• Capacity that is not shared. The platform-wide concurrency ceiling that sits above your organization limit on the shared cloud becomes your own.
• A blast radius that contains only your traffic.
• An upgrade cadence that can be agreed rather than assumed.

What it requires — a scoping conversation covering region, expected peak concurrency, provider accounts and network ingress. Commercial terms are per agreement.

Your compute, our control plane

You run the platform on your own instances or private cluster; billing stays on Graine's hosted service.

What it gives you — call audio, transcripts, agent configuration and every provider credential stay inside your network and never transit ours. Model, speech and telephony traffic goes from your infrastructure to your providers directly. You choose the region, the hardware and the network posture.

Three kinds of request leave your network, all over HTTPS to our API host:

What it requires

• Egress on TCP/443 to api.graine.ai, via NAT if the instances sit in private subnets.
• Your egress address allowlisted on our side.
• Generous HTTP timeouts — 30 seconds read, 10 seconds connect. Five seconds is not enough for a round trip to our hosted API, and produces spurious "billing unavailable" failures.

The consequence to plan for. With the funding gate enabled and configured to fail closed — the setting we document — loss of egress to our control plane stops you placing calls. That is intended: it prevents unmetered calling. Confirm it is acceptable to your network team before choosing this model, and verify the path from the host — it prints 200 when the path works:

curl -sS -m 30 https://api.graine.ai/v2/health

Fully local billing is not offered for this model.

What runs in a deployment

Every model above runs the same platform:

The call path

Your request  ──▶  Graine API  ──▶  telephony  ──▶  carrier  ──▶  callee
                                       │
                     conversation  ◀═══╧═══▶  the live call's audio

Bringing it up

For a dedicated instance or your own compute, Graine provides the deployment kit and brings the platform up with your team. You provide a Linux host (or your cluster), outbound HTTPS to your model, speech and telephony providers, and TLS in front of the API and the live-call endpoint.

Trade-off — on one host, every component shares a failure domain. That is the right choice where operational simplicity outweighs redundancy, and it is the reason a dedicated instance is scoped with its own capacity target rather than assumed to be highly available by default.

Scaling within a deployment

The live-call tier holds one connection per live call for the whole call, so its ceiling is a connection count, not a request rate. At higher volumes it runs as its own tier — for example four replicas behind their own load balancer, each capped at 2,500 connections, on a host separate from the API. The API, agent and telephony services hold no per-request state and scale by adding replicas. Adding replicas on a single host raises throughput; it does not add availability, because the host remains one failure domain.

Capacity

Capacity is governed, not merely observed. Before every dial, a slot is taken at four levels:

Global (platform ceiling)
  └── Organization
        └── Agent
              └── Campaign (calls placed by a campaign)

Each level is taken atomically, so two calls can never both take the last slot. A slot that is never released — a lost hang-up — expires on its own, and capacity is reconciled continuously against the calls actually in flight.

Defaults for a new organization:

The organization and per-agent limits can be changed for your organization, and you set a campaign's ceiling yourself. Older organizations started from earlier defaults (see Rate limits), and yours may have been changed since.

Raising capacity for a large campaign takes effect within a minute — no release on either side. Read your live values from GET /v2/user/me rather than assuming the defaults:

curl -sS https://api.graine.ai/v2/user/me \
  -H "Authorization: Bearer gat_YOUR_API_KEY"

{
  "organization_id": "organization-live-example",
  "plan": "trial",
  "concurrency": {
    "max": 3,
    "current": 2,
    "agent_max": 3,
    "global_max": 1000,
    "enforced": true
  },
  "rate_limits": {
    "default_per_minute": 1000,
    "calls_per_minute": 600,
    "executions_per_minute": 600
  }
}

Live-call capacity

Each conversation-service instance accepts up to 24,000 concurrent call connections by default. Past the cap it refuses new connections (WebSocket close code 1013, "Service overloaded") rather than degrading every call already in progress — a refusal the caller can see and the metrics record. A dedicated conversation tier sets a lower cap per replica, trading density for a smaller blast radius.

Those enforced caps are the numbers we stand behind. For a validated figure at your volume, ask for a load test against your configuration and we will run one.

Health and monitoring

Point your uptime monitoring at GET https://api.graine.ai/v2/health — see Checking the API is up. For a dedicated instance or your own compute, the deployment kit includes liveness, readiness and metrics endpoints for every component, and we wire them into your monitoring with you.

Not offered today

Stated plainly, so it does not surface late in an evaluation:

• Air-gapped installation. Every model requires egress to our control plane for funding and metering.
• A managed container-service (multi-zone) topology. Raise it during scoping if it is a requirement for your account.
• Offline licensing, signed release artifacts for self-hosted deployment, or a published self-hosted upgrade and rollback procedure.
• Multi-region active-active.