API Gateway overview

The API Gateway publishes internal workloads—agents, functions, serverless services, container apps, MCP servers, the vector database, Pub/Sub, and MemoryStore instances—to secure internet endpoints.

It is the only way a resource on this platform gets an address on the internet. One publishing path means one place your access policy lives and one audit trail, rather than a per-product switch each with its own idea of what "exposed" means.

Core capabilities

An endpoint is an internet-facing gateway route pointing to a project resource. Endpoints decouple public access policies (authentication, domain names, rate limits, IP allowlists) from underlying workload runtime behavior.

Endpoint components

Component	Function	Default Setting
Name	Endpoint identifier and default URL hostname prefix.	Required
Target	Internal workload or data service receiving traffic.	Required
Domain	Public hostname (platform-provided domain or custom domain).	Platform domain (*.apps.codyhill.net)
Authentication	Caller identity verification (none, jwt, apikey).	none (Open)
IP Allowlist	CIDR network restriction rules.	Unrestricted
Rate Limit	Request ceiling per caller per time window.	Unrestricted

Publishable target types

Resource	Target	Takes a name?	How it is reached
Agent	agent	yes	Web requests
Function	function	yes	Web requests
Serverless service	serverless	yes	Web requests
Container app	container	yes	Web requests
MCP server	mcp	yes	Web requests
Vector database	vectordb	no — covers the whole project	Web requests
Pub/Sub	pubsub	no — covers the whole project	Raw connection
MemoryStore	memorystore	yes	Raw connection

What you can publish has a section per type: the exact command, the protections that type supports, and the one thing about it that catches people out.

Scale-to-zero keeps working

Publishing an agent, function, serverless service, container app or MCP server preserves scale-to-zero. An inbound request to an idle workload wakes an instance and waits for it, so a published address does not oblige you to keep anything warm.

A raw connection cannot check a credential

Pub/Sub and MemoryStore speak their own binary protocols, so there are no requests for the gateway to read. An authentication mode or a rate limit on one of those would be a protection that does not exist, and the API refuses both rather than accepting them and doing nothing. Address allow lists still work, and the service's own credential is what lets a caller in.

Protection modes

API Gateway provides three distinct authentication modes:

• Open (none): Publicly accessible endpoint without edge credential checks. Useful for public endpoints, documentation sites, or webhooks verified in application code.
• JSON Web Tokens (jwt): Edge validation for standard OIDC / OAuth2 tokens issued by your identity provider (e.g. Auth0, Okta).
• API Keys (apikey): Gateway-issued API keys sent in the X-API-Key header with automatic expiration, rotation, and usage tracking.

Feature comparison

Feature	Crusoe AI Platform API Gateway	Cloud Provider Gateways
Deployment Model	Direct one-click publishing	Multi-step API / Stage / Deployment setup
Authentication Options	Native Open, OIDC JWT, or Gateway API Keys	IAM, Cognito, Custom Authorizers, API Keys
Network Security	Native CIDR IP allowlists	Network ACLs / WAF integrations
Traffic Throttling	Built-in per-caller rate limiting	Usage plans and throttling tiers
Custom Domains	Automatic TLS certificate provisioning	Custom domain mappings and certificate imports

Next steps

• What you can publish — A section per resource type, with the exact command for each.
• Publish an endpoint — Step-by-step guide to deploying public routes.
• Authentication — Configure JWT, API keys, or open access.
• Rate limits — Protect endpoints with request throttling.
• IP allowlists — Restrict access to specific IP CIDR ranges.
• Custom domains — Attach custom domain names with automated TLS.