Private Deployment - Bring Your Own Cloud (BYOC)

👋

Reach Out For Access

Interested in BYOC? We'll make it self-serve in the future, but for now access is limited to Enterprise customers. Please reach out to our team to get access: [email protected]

BYOC at a glance

Bring-Your-Own-Cloud lets you run all Freeplay services inside your own AWS, GCP, or Azure account. You keep full control over data, IAM roles, and network boundaries while Freeplay still updates and supports the software.

Why choose BYOC?

• All prompts and responses remain inside your cloud; Freeplay never receives or stores them. – Meets strict data-residency or internal-only policies.
• Reduced vendor-risk reviews – Auditors see a familiar cloud footprint that you govern.
• Same product feature velocity – Freeplay’s automated control plane delivers signed updates to the Freeplay application.
• Minimal DevOps overhead – when compared to alternative models for privately hosted software, like installing & updating Docker images and setting up & maintaining all of your own serving and database infrastructure

Architecture Overview

BYOC Deep Dive

How BYOC works

1. Prepare your environment - create an empty cloud project or sub-account.
2. Deploy the Freeplay agent – Freeplay generates a bundle for you with the installer script. It will guide you through the type of deployment you want (Publicly accessible domain or Private only).
3. Provision cluster – Freeplay uses Terraform to provision managed SQL (PostgreSQL), Bucket Storage, and Kubernetes. The freeplay agent uses Helm to spin up elastic search, NATS, and the Freeplay web application.
4. Stay current – the agent polls Freeplay’s control plane for releases and applies rolling upgrades. This is set to poll every 4 hours by default. We suggest turning on 'automatic updates' to ensure you receive the latest security fixes and features.

# Example quick-start (AWS)
./freeplay_up.sh

Prerequisites

Presently we provide terraform that provisions everything but the account/project/subscription. Some tweaks may apply depending on the networking architecture by your team. Knowing your network configuration can help expedite the process.

Google Cloud APIs and IAM

These APIs will be necessary for the deployment on Google Cloud. We use least-privileged permissions where possible. We suggest keeping things isolated by project. The ./freeplay_up.sh script will request these APIs prior to installing the terraform.

# APIs that should be on

## Needed for GKE
compute.googleapis.com 				   
container.googleapis.com 

## Needed so GKE workload identity can access other Google services
iam.googleapis.com										

## Needed for provisioning DB, adding users that the app uses				
sqladmin.googleapis.com						

## Needed for secure secrets and encryption of data into Postgres/Buckets
secretmanager.googleapis.com			
cloudkms.googleapis.com						

## Needed for ability to provision certificate so site is securely accessible
dns.googleapis.com									
certificatemanager.googleapis.com
servicenetworking.googleapis.com	

## Needed to store events and multimedia assets securely
storage.googleapis.com								

## Needed for access to Vertex
aiplatform.googleapis.com							

## These may be necessary for any VPC peering scenarios
networksecurity.googleapis.com				
networkmanagement.googleapis.com
privateca.googleapis.com

# IAM Roles

## For asset and data buckets that are provisioned in deployment (nothing else)
roles/storage.objectAdmin

## For cluster service account can access Google Managed Services
roles/iam.workloadIdentityUser
roles/cloudsql.client
roles/secretmanager.secretAccessor
roles/cloudkms.cryptoKeyEncrypterDecrypter

## For cluster nodes to provide metrics
roles/logging.logWriter
roles/monitoring.metricWriter
roles/monitoring.viewer
roles/stackdriver.resourceMetadata.writer
roles/storage.objectViewe

## For the designated cluster admin (optional)
roles/container.admin

Security & compliance

• Data residency – all sensitive customer data including prompts, responses, and evaluations stay in your cloud account. Optional ability to share support bundles for troubleshooting scenarios.
• Secrets – stored in your cloud KMS‐backed secret manager; never transmitted to Freeplay.
• Updates – releases are signed and verified before install; only metadata (version, health ping) is sent to the control plane.

Costs

• Freeplay subscription – BYOC is available only for Enterprise-tier contracts. Please contact Sales for more info about access.
• Your cloud – you pay for all nodes, database, Elasticsearch, storage, and egress. Typical mid-sized install runs ≈$1.2k-$2k/mo in AWS us-east-1.

BYOC Outbound-Egress Matrix

Rows 1, 2 and 5 are always required for a supported install. Row 4 is required only when your workloads invoke external hosted models; BYOC also supports running local/onsite models if you need zero data egress for LLM traffic.

Key Points

• You decide which LLM providers and regions to enable in the Freeplay UI or Helm values.
• All calls use HTTPS (TLS 1.2+).
• Freeplay's log policy prevents user content from landing in Datadog.
• If you need a completely offline install, talk to us. An artifact-mirror and on-prem observability stack are on the roadmap.

FAQ