All guides

Bring your own cloud

Plan your first customer-cloud deployment

Define the account, access model and operating responsibilities before bringing your SaaS into a customer’s infrastructure.

  • Advanced
  • 4 min read
  • 6 sections
  • Updated
Cover illustration for Plan your first customer-cloud deployment, advanced levelBring your own cloudAdvanced · 795c
On this page6 sections
  1. 01Start with the customer’s requirement
  2. 02Agree the deployment boundary
  3. 03Assign operating responsibilities
  4. 04Choose a repeatable application pattern
  5. 05Prepare an exit path
  6. 06Scope the pilot

Start with the customer’s requirement

Ask what the customer needs from running your software in their account. The answer might be control over infrastructure, a chosen deployment region, a procurement requirement or integration with an existing environment.

Write down the specific requirement. It will guide the topology and access model more effectively than a broad request for “private cloud”.

Agree the deployment boundary

Identify the account, region and environments involved. List the application services, persistent data stores and external services your software needs.

Make the boundary visible to both teams: what runs in the customer’s account, what remains with you, and which connections cross between them. Include operational data such as logs and support diagnostics in that discussion.

The deployment boundary
Three columns. On the left, the vendor's side: release artifacts and the support team. In the middle, the crossing: a scoped access role and a diagnostics export. On the right, inside the customer's cloud account: the application cluster, the database and the logs bucket.Your side (vendor)CrossingCustomer cloud accountRelease artifactsimages · migrationsSupport teamreads diagnosticsScoped access rolegranted by customerDiagnostics exportagreed fields onlyApp clusteryour servicesDatabasecustomer dataLogs bucketreleasedeploymigrateread
  • Release artifacts connects to Scoped access role (release).
  • Scoped access role connects to App cluster (deploy).
  • Scoped access role connects to Database (migrate).
  • Diagnostics export connects to Support team (read).
  • Logs bucket connects to Diagnostics export.
Figure 1. Draw the boundary before the first install: what runs in the customer’s account, what stays with you, and every connection that crosses it.

Assign operating responsibilities

Agree who performs each recurring task before the first deployment:

  • Approving and granting infrastructure access.
  • Releasing application updates and database migrations.
  • Maintaining the cluster and its supporting services.
  • Monitoring the application and responding to incidents.
  • Creating backups and testing restoration.
  • Reviewing and paying for cloud usage.

BYOC gives the customer ownership of the infrastructure. It still needs an explicit operating agreement.

Operating agreement
Recurring taskVendor teamCustomer team
Grant infrastructure accessNoYes
Release updates and migrationsCustomer approves the windowYesPartial
Maintain the clusterPartialYes
Monitor and respond to incidentsYesPartial
Back up and test restoresPartialYes
Review and pay for cloud usageNoYes
Figure 2. One possible split of the six recurring tasks. Yours will differ; what matters is that no row is left blank.Illustrative · one possible agreement

Choose a repeatable application pattern

Document the common services and dependencies that every customer needs. Keep customer-specific values separate: domains, credentials, sizing and external integrations.

Start with one pilot customer. Exercise installation, an application update and a recovery scenario before treating the pattern as ready for repeated deployments. See Kapten for SaaS vendors for the intended workflow.

  1. Install
    Common pattern plus customer values.
    Gate: Serves traffic
  2. Update
    A release and a migration.
    Gate: No downtime surprise
  3. Recover
    Restore into a test environment.
    Gate: Restore timed
  4. Repeat
    Next customer, same pattern.
Figure 3. A pilot earns the right to repeat: each scenario is exercised once, end to end, before the next customer.

Prepare an exit path

Define what happens when access is revoked or the commercial relationship ends. Agree which resources remain, how the customer obtains an inventory, and who takes over maintenance and application delivery.

Infrastructure ownership is most useful when the team inheriting it knows how to operate it. Include the handover in the original plan.

An exit, planned on day one
  1. Notice
    End of the relationship agreed
    Date and scope written down by both teams.
  2. Inventory
    Customer receives the inventory, In progress
    Every resource, what it is for, what data it holds.
  3. Handover
    Operations handed over, In progress
    Who maintains the cluster and ships updates next.
  4. Revoke
    Vendor access role removed, Queued
    By the customer, in their own account.
  5. After
    Workloads keep running, Live
    The infrastructure stays with its owner.
Figure 4. The exit in the order it should happen: inventory and handover first, access removed last, and the customer’s workloads never stop.Illustrative · one possible exit

Scope the pilot

Bring your architecture, the customer’s constraints and your operating model to the early-access conversation. Confirm available capabilities before promising automated fleet management, reseller workflows or a particular deployment schedule.

Build with Kapten

Start with one service.
Build from there.

Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.

Request early access Explore the demo

Free during early access. No card required. Cloud usage billed separately.