Bring Your Own Cloud is part of every Apollo product

Infrastructure should remain under the control of the teams responsible for it.

That principle sits at the centre of Apollo Deploy, Apollo Signal, and every product we plan to build after them.

Some teams want a fully managed service. They want to connect an application, configure a product, and let Apollo operate the underlying infrastructure.

Other teams need greater control. They may already have cloud agreements, security policies, private networks, compliance requirements, regional restrictions, or infrastructure their organisation has spent years standardising.

Those teams should not have to choose between using an Apollo product and keeping control of their cloud environment.

That is why Apollo products support Bring Your Own Cloud, or BYOC.

Apollo Deploy can operate applications on infrastructure you control or through Apollo Cloud. Apollo Signal can send transactional email through your own AWS account while still providing the delivery tooling around it.

Every future Apollo product will be designed with the same option.

Your infrastructure should remain yours

Cloud infrastructure is not only a collection of servers and service accounts.

It contains an organisation’s security boundaries, billing agreements, audit history, networking rules, data policies, operational knowledge, and existing commitments.

Moving a workload into a completely separate managed platform can mean giving up more than control of where it runs.

It can also mean:

• Paying different infrastructure rates.
• Moving activity outside existing audit systems.
• Introducing another security boundary.
• Sharing infrastructure reputation with other customers.
• Rebuilding compliance controls.
• Depending on proprietary operational workflows.
• Making future migration more difficult.

Apollo should make infrastructure easier to operate without requiring teams to surrender ownership of it.

BYOC gives organisations a middle path.

Apollo provides the product, control plane, workflows, monitoring, automation, and operational experience. The customer retains ownership of the cloud resources used to perform the underlying work.

Apollo Deploy was built around this model

Apollo Deploy is being built as an open application platform that can run on your infrastructure or through Apollo Cloud.

The goal is to give teams one operating model for deploying and managing applications across different environments.

A team may choose to:

• Run Apollo Deploy entirely on infrastructure it controls.
• Use Apollo Cloud for both the platform and application workloads.
• Use an Apollo-managed control plane with customer-owned infrastructure.
• Run public workloads on Apollo Cloud and private workloads internally.
• Combine multiple cloud providers, regions, servers, or private environments.

The deployment experience should remain consistent across those choices.

Applications should still be planned, authorised, deployed, monitored, and audited through the same platform. Humans, command-line tools, CI systems, and AI agents should operate through the same controlled capabilities.

The infrastructure location changes.

The operating model does not.

Apollo Signal brings BYOC to transactional email

Transactional email is infrastructure.

It carries password resets, login codes, invoices, receipts, security alerts, account notifications, and messages people depend on when something important happens.

For many organisations, the account sending those messages matters as much as the API used to create them.

Apollo Signal Bring Your Own Cloud allows teams to send email through their own AWS account while continuing to use Signal’s managed delivery platform.

Your application sends through the Apollo Signal API. Signal handles the delivery workflow around each message. The final sending route remains inside the AWS account your organisation owns and governs.

This gives teams control over:

• AWS infrastructure ownership.
• Sending reputation.
• Cloud billing.
• Access policies.
• Regional configuration.
• Cloud audit history.
• Existing AWS agreements and discounts.

Apollo Signal remains responsible for making the email workflow usable.

The route is yours, while Signal manages delivery

Bring Your Own Cloud does not mean handing teams a collection of low-level AWS services and wishing them luck.

Apollo Signal continues to provide the operational layer around transactional email.

This includes capabilities such as:

• Domain verification.
• Email API access.
• Message processing.
• Bounce and complaint handling.
• Suppression lists.
• Webhooks.
• Delivery analytics.
• Message events.
• Delivery monitoring.
• Connection health checks.
• Failure notifications.

The customer-owned AWS account becomes the sending plane.

Apollo Signal remains the delivery platform around it.

This separation gives teams the benefits of infrastructure ownership without requiring them to build and operate an entire transactional email service internally.

A connection with narrow permissions

BYOC should not require customers to share permanent cloud credentials.

Apollo Signal’s AWS connection is designed around scoped access and short-lived sessions.

An account administrator begins the connection from Apollo Signal and receives a prepared AWS request. The administrator can review the requested permissions before approving the connection.

AWS then returns an identifier that allows Signal to request temporary access through the approved role when email needs to be sent.

No long-lived access key or secret needs to be copied into Apollo Signal.

The connection is intended to remain narrow:

• Apollo requests only the permissions required for email delivery.
• Access is granted through a customer-approved AWS role.
• Sessions are temporary and expire automatically.
• Activity remains visible through the customer’s AWS audit systems.
• The customer can revoke the connection from its own cloud account.

Apollo should receive the minimum authority required to perform the task.

This principle will also apply to future BYOC integrations across Apollo products.

Why we offer BYOC

BYOC is not included because every customer wants to operate cloud infrastructure.

Many do not, which is why Apollo will continue providing fully managed products.

We offer BYOC because infrastructure requirements are not the same for every organisation.

Keep existing cloud economics

Large organisations often have negotiated cloud pricing, committed spend, credits, or purchasing agreements.

Moving a workload onto provider-owned infrastructure may prevent the organisation from using those benefits.

With BYOC, the underlying usage remains in the customer’s cloud account and follows the commercial relationship it already has with that provider.

For Apollo Signal, that means email sending can use the customer’s AWS pricing and account-level arrangements.

For Apollo Deploy, it means application workloads can use infrastructure the customer already owns or has committed to paying for.

Preserve security boundaries

Some workloads cannot be moved outside infrastructure controlled by the organisation.

A company may require private networking, customer-managed encryption, specific identity policies, restricted service roles, or internal security monitoring.

BYOC allows Apollo to operate within those boundaries rather than forcing the organisation to create an entirely separate one.

Retain auditability

When infrastructure activity happens inside a customer-owned cloud account, the organisation can monitor it through the systems it already uses.

Teams can review cloud access, role assumptions, API activity, infrastructure changes, and resource usage within their existing audit process.

Apollo still records product-level activity, while the cloud provider records activity at the infrastructure level.

Together, those records create a clearer account of what happened.

Maintain isolated reputation and resources

Some infrastructure has a reputation or history attached to it.

Transactional email is one example.

With Apollo Signal BYOC, sending activity and reputation remain associated with the customer’s own AWS account rather than being mixed into a general shared sending environment.

The same principle may apply to dedicated compute, networking, storage, model execution, data processing, or other future Apollo products.

Reduce unnecessary lock-in

A managed service should earn continued use through value, not through making migration artificially difficult.

BYOC keeps important infrastructure resources within the customer’s ownership.

The customer retains its cloud account, billing relationship, audit history, and underlying resources. Apollo provides the operating layer around them.

This makes the relationship clearer.

Customers remain because Apollo makes the infrastructure easier to use, not because Apollo has made leaving prohibitively painful.

Managed products still matter

Bring Your Own Cloud is an option, not a requirement.

Running infrastructure carries responsibility.

Teams must manage cloud accounts, budgets, quotas, service availability, security policies, regional capacity, and provider-specific constraints.

Many developers and organisations would rather not take on that work.

Apollo-managed infrastructure exists for those teams.

With Apollo Cloud or Apollo-managed Signal delivery, Apollo can handle more of the underlying operational burden, including:

• Infrastructure provisioning.
• Platform maintenance.
• Service updates.
• Capacity planning.
• Security hardening.
• Availability.
• Monitoring.
• Recovery.
• Provider configuration.
• Operational support.

The managed option is designed for convenience.

The BYOC option is designed for control.

Both should use the same product experience wherever possible.

Shared responsibility without confusion

BYOC creates a shared responsibility model.

The customer owns and governs the cloud account. Apollo operates approved product capabilities through a limited connection.

For Apollo Signal:

• The customer owns the AWS account and its configuration.
• The customer controls the granted permissions.
• The customer pays AWS for cloud usage.
• Apollo Signal manages email workflows, events, analytics, and delivery tooling.
• Apollo monitors the health of the connection.
• The customer can revoke access through AWS.

For Apollo Deploy:

• The customer may own the infrastructure running its applications.
• Apollo Deploy coordinates deployment and operational workflows.
• Policies control which actions humans and agents may perform.
• Plans describe intended infrastructure changes.
• Audit records show what was requested, approved, and executed.

The boundaries should be explicit before the connection is created.

BYOC should never mean silently shifting responsibility between the customer, Apollo, and the cloud provider.

Continuity when a customer-owned route fails

Customer ownership should not mean that an avoidable interruption immediately becomes an application outage.

Apollo products can provide managed continuity options where the workload allows them.

For Apollo Signal, the customer-owned AWS route remains the primary delivery route. Signal monitors the health of that connection and can notify the team when the route becomes unavailable.

Depending on the organisation’s configuration and policies, Signal may fall back to Apollo-managed delivery infrastructure so critical transactional email can continue to be sent.

Fallback should remain a deliberate customer choice.

Some organisations may prioritise uninterrupted delivery. Others may require that messages never leave customer-owned infrastructure, even during an outage.

Apollo Signal should support both operating policies rather than assuming every organisation has the same risk model.

BYOC and AI agents

Apollo is being built for humans, command-line tools, APIs, CI systems, and AI agents.

As agents gain the ability to deploy applications, investigate failures, or perform operational work, cloud access becomes an important safety boundary.

An agent should not receive an unrestricted administrator credential simply because it needs to perform one deployment or send one category of message.

BYOC connections should expose narrow, auditable capabilities through Apollo’s operating layer.

The agent requests an action through Apollo. Apollo evaluates the applicable permissions and policies. The platform then uses its scoped cloud connection to perform only the approved operation.

This creates a safer separation:

• The agent understands the requested outcome.
• Apollo controls planning, permissions, and execution.
• The cloud provider enforces the underlying role.
• The customer retains ownership and the ability to revoke access.

BYOC is therefore not only about cloud billing or infrastructure preference.

It is also part of building a safer boundary for autonomous systems.

Every future Apollo product will support BYOC

Bring Your Own Cloud is not an isolated Apollo Signal feature.

It is a product principle for Apollo as a whole.

Every future Apollo product will be designed with a BYOC option where customer-owned infrastructure is technically possible.

That may include products involving:

• Application deployment.
• Transactional email.
• Databases.
• Object storage.
• Observability.
• Build infrastructure.
• Background jobs.
• AI model execution.
• Data processing.
• Networking.
• Security operations.
• Other infrastructure services.

The exact integration will differ by product.

Some products may connect to an existing customer resource. Others may provision resources into the customer’s account. Some may support a hybrid model where Apollo manages the control plane while execution remains inside customer-owned infrastructure.

The principle remains the same:

Apollo should provide the operating experience without requiring ownership of every resource involved.

How BYOC will be priced

Apollo-managed and BYOC products have different cost structures.

With a fully managed product, Apollo pays for and operates more of the underlying infrastructure. Pricing must therefore include infrastructure usage, platform operations, reliability, and support.

With BYOC, the customer pays the cloud provider directly for the infrastructure running in its account.

Apollo pricing covers the product layer around that infrastructure, which may include:

• Control-plane services.
• Workflow orchestration.
• Monitoring.
• Analytics.
• Policy management.
• Audit history.
• Integrations.
• Automation.
• Support.
• Enterprise security features.
• Managed connection health.
• Operational continuity features.

For Apollo Signal, Bring Your Own Cloud is available as part of the Enterprise plan.

Customers pay AWS directly for the email infrastructure and sending usage inside their account. Apollo Signal pricing covers the delivery platform, management tooling, analytics, monitoring, integrations, and enterprise support around that route.

Future Apollo products may offer BYOC across different plans depending on the complexity and operational cost of each integration.

Pricing should remain clear about what the customer pays Apollo for and what the customer pays the cloud provider for.

No one should need a diagram, a financial investigator, and three browser tabs to discover who is charging them for compute.

What we want to accomplish

BYOC is part of a broader goal for Apollo.

We want to build infrastructure products that are easier to use without making them harder to own.

That means giving teams the ability to:

• Choose between managed and customer-owned infrastructure.
• Keep workloads inside existing cloud boundaries.
• Use established cloud pricing and agreements.
• Retain cloud-level audit records.
• Apply narrow and revocable permissions.
• Keep humans and agents inside the same operational model.
• Move between infrastructure environments without rebuilding the product workflow.
• Adopt Apollo without surrendering long-term control.

Apollo should reduce the work involved in operating infrastructure.

It should not require teams to give up the infrastructure decisions that matter to them.

Your cloud, operated through Apollo

Apollo Deploy can run applications on your infrastructure or through Apollo Cloud.

Apollo Signal can send transactional email through your AWS account or through Apollo-managed delivery infrastructure.

Future Apollo products will follow the same model.

Use Apollo’s managed infrastructure when convenience is the priority.

Bring your own cloud when ownership, economics, security, auditability, or compliance requires it.

The product experience should remain coherent across both.

That is the promise behind Apollo BYOC: your infrastructure remains yours, while Apollo makes it easier to operate.