Deploying in Your Google Cloud Project
FunnelStory can run as a single-tenant deployment inside your own Google Cloud project, instead of on FunnelStory's multi-tenant cloud. Choose it when your security or data-residency policies require customer data to stay in infrastructure you own: the application, its database and its storage all run in your project, behind your network controls, and your users reach it on your private network.
This page is an overview for your platform, cloud and security teams. Deployments in your own project are arranged with your FunnelStory account team, who provide the detailed deployment package during onboarding. For AWS, see Deploying in Your AWS Account.
How it works
FunnelStory runs in a VPC in your Google Cloud project. You own the project, the network around it, and who can reach it.
| Runs in your project | Stays with FunnelStory |
|---|---|
| The FunnelStory application, on Google Kubernetes Engine (GKE) | The deployment automation and its source code |
| Your data: the database (Cloud SQL for PostgreSQL), file storage (Cloud Storage) and application secrets (Secret Manager) | Container images, which are copied into your Artifact Registry for each release |
| Encryption keys (Cloud KMS) and logs (Cloud Logging) | |
| An internal load balancer for your users |
Your customer data stays in your project. The application reaches out only to the systems you connect it to, such as your CRM, data warehouse, support tool, LLM provider and messaging tools.
Choosing who operates it
You can run the deployment in one of two ways. Decide with your FunnelStory account team before onboarding.
| FunnelStory operates | You operate | |
|---|---|---|
| Infrastructure | FunnelStory's automation creates and maintains it in your project | Your team creates and maintains it, from FunnelStory's requirements |
| Releases | FunnelStory deploys each release | FunnelStory copies each release into your Artifact Registry and starts your deployment pipeline. Your pipeline rolls it out. |
| Best when | You want FunnelStory to run the application for you | Your policies require your team to make every infrastructure change |
Either way, the application, your data and the network stay in your project.
What you provide
Before the first deploy, your team prepares:
- A Google Cloud project and region. We recommend a dedicated project for FunnelStory.
- A VPC network with a private subnet in your chosen region.
- A hostname and certificate for the address your users will use, such as
funnelstory.example.com. - Private access for your users, from your corporate network or VPN to the internal load balancer.
- Outbound access from the VPC to the services you connect FunnelStory to, for example through Cloud NAT or your own egress path.
- Single sign-on with your identity provider. See Single Sign-On (SSO).
If your organization uses organization policies or other guardrails, such as restrictions on external IP addresses, allowed regions or service account keys, share them with FunnelStory before the first deploy.
How FunnelStory's access is controlled
FunnelStory's access to your project follows two principles:
- Changes go through automation, not people. FunnelStory's deployment pipeline reaches your project through Workload Identity Federation, with short-lived credentials and no service account keys. Only reviewed changes can use it.
- People have no standing access. If an incident needs hands-on work, your team grants FunnelStory engineers time-limited access for that incident, and it expires on its own. FunnelStory can't grant itself access.
You create the identities FunnelStory uses and decide their roles, and you can revoke them at any time. FunnelStory doesn't need organization, folder or billing access.
Shared responsibility
| Area | You | FunnelStory |
|---|---|---|
| Project and network | The project, VPC, firewall rules, routing and network monitoring | The application's network requirements |
| Identity and access | Your project administrators, your identity provider, and approving incident access | Application roles and permissions inside FunnelStory |
| Application | Approving changes to infrastructure you control, and running releases if you operate the deployment | Building releases, and deploying and operating the application if FunnelStory operates it |
| Data | Data classification and retention policies | Encryption in transit and at rest, and backups |
| Security monitoring | Project-level logging, threat detection and scanning | Application audit logging, and fixing vulnerabilities in FunnelStory's components |
| Incidents | Project and network issues | Application issues, with joint triage through a shared channel |
Google is responsible for the security of the cloud itself: its data centers, the GKE control plane and the managed database engine. Response times, maintenance windows and other commitments are set in your agreement with FunnelStory.
Getting started
- Talk to your FunnelStory account team about scope: the region, the operating model, the data sources to connect, and your LLM provider.
- Review the deployment package. FunnelStory provides the access, network and sizing requirements for your platform and security teams.
- Prepare your project and set up Workload Identity Federation for FunnelStory's pipeline, following the package.
- Deploy. FunnelStory deploys the application, or your team deploys it from FunnelStory's requirements, and you point your hostname at the load balancer.
- Connect single sign-on and your data sources, and agree the shared support and incident process.
Related
- Deploying in Your AWS Account — the same deployment on AWS.
- Security — how FunnelStory protects data.
- Single Sign-On (SSO) — connect your identity provider; use your own hostname in a private deployment.
- AI Providers — bring your own LLM provider.
- Data connections — the sources FunnelStory reads from.