Creator businesses

Run the back end of a creator business on Quake AI: archive of record, batch processing, distribution origin, and an audience-owned surface. You operate transcoding, inference workers, the edge proxy, and the audience site; Quake AI provides CPU compute, object storage, networking, and floating IPs.

What this is for#

Creators and small studios that want to own their archive and audience run the back end themselves. Quake AI provides object storage for masters and renders and CPU compute for batch transcode and inference workers; you operate the processing pipeline, edge proxy, and audience surface.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

Three validated templates compose the back end: the edge reverse proxy publishes the audience site or API with automatic HTTPS, the Creator-AI inference worker runs batch transcode and inference jobs, and S3 Storage with ACLs holds the archive of masters and renders.

1. Creator and audience. Creators upload masters and manage the pipeline; the audience reaches the distribution site or API over HTTPS.

2. Edge reverse proxy with TLS. The edge reverse proxy runs Caddy on a floating IP, obtains a certificate for your domain, and routes requests to the audience site or API.

3. Audience site or API. A membership site, distribution origin, or private API runs on Compute VMs behind the edge reverse proxy.

4. Batch and inference workers. Transcode, caption, summarize, and index jobs run on Compute workers. The Creator-AI inference worker template scaffolds the CPU inference stack.

5. Object Storage archive. Masters, renders, captions, and distribution assets live in S3-compatible Object Storage, which both the workers and the audience tier read from.

Services involved#

Get started#

• Simple VM template: single VM with floating IP for batch workers, ingest hooks, or a private processing node.
• Deploy the Simple VM template: step-by-step walkthrough for a single Compute instance with a floating IP.
• Edge reverse proxy template: Caddy-based public tier for a membership site, API, or distribution origin.
• Deploy the edge reverse proxy template: publish a membership site or API with automatic HTTPS.
• Deploy the Creator-AI inference worker template: CPU inference stack for transcribe, summarize, and index routes.
• Upload objects to Object Storage: land raw media, renders, and exports in the bucket your templates provision.
• OpenTofu template library: browse validated IaC starting points for creator back-end layouts.

Estimate the cost#

Migrating an existing creator business workload?#

Move a creator or studio back end that already runs on AWS EC2 and S3, Azure VMs and Blob, Google Compute Engine and Cloud Storage, or another hyperscaler where you operate the integration layer yourself. The outcome is the same media archive, processing workers, and audience-facing origin on Quake AI, with object buckets, worker fleets, and public endpoints cut over in a controlled order.

Follow this cutover path. Each step links an existing migration page; this section composes those pages into a workload-shaped sequence rather than duplicating their steps.

1. Map your source provider. Start with the concept-translation page for your current cloud: Coming from AWS, Coming from Azure, Coming from GCP, Coming from DigitalOcean, or Coming from Hetzner.

2. Stand up the target shape on Quake AI. Pick the template that matches the workload: Simple VM for batch or inference workers, or edge reverse proxy for an audience site or API with automatic HTTPS.

3. Move compute workloads. Rebuild transcoding, inference, and automation workers with Migrate from EC2 (or the matching compute migration page for your source provider).

4. Move object and media data. Sync master files, renders, captions, and distribution assets with Migrate from S3 (or the matching object migration page for your source provider).

5. Cut over the public endpoint. Stage the audience site or API behind the edge reverse proxy, validate signed URLs and embed behavior, then switch DNS to its floating IP or update client base URLs for private integrations.

Workload-specific cutover callouts#

• Media-asset bucket sync. Copy source buckets before you switch production traffic. Validate object counts, checksums on large masters, and CDN or signed-URL behavior against the Quake AI bucket paths you provisioned.
• Worker VM rebuild. Batch transcode, inference, and ingest workers rarely lift-and-shift cleanly. Rebuild images on Quake AI, replay cloud-init or container bootstrap, and run a full pipeline dry run before you cut over scheduled jobs.
• DNS and endpoint switch. Lower TTL on the production hostname several days before cutover. Keep the source origin warm until playback, upload, and webhook error rates stabilize. Roll back by switching DNS or client base URLs back to the old endpoint if health checks fail.
• CPU-only workloads. CPU workers fit batch transcode, smaller models, and caption or summarize jobs on Quake AI (compute FAQ). GPU-heavy transcode or real-time inference at production scale needs accelerators outside this flavor catalog.

Considerations and limits#

• You operate the pipeline. Quake AI provides compute, storage, networking, and floating IPs; the transcode pipeline, inference workers, edge proxy, and audience application are yours to build and operate under the shared responsibility model.
• CPU-only compute. Compute is AMD EPYC with no GPU option (compute FAQ). Size workers for batch transcode and smaller models; GPU-heavy real-time inference needs a different hosting path.
• No managed database or CDN. Catalog and metadata stores run on Compute or Block Storage you operate. Static and media acceleration requires a third-party CDN in front of the origin.
• Flat egress. Quake AI applies a no-egress-fee policy for outbound transfer, which suits creators who serve large media files to an audience.
• Three US regions. All current regions are in the United States. Global distribution needs CDN coverage in front of the origin.
• Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. See Compliance and certifications for the platform scope.