Open source is how Apollo Deploy earns your trust

Open source is not a badge we put on the homepage.

It is not a marketing label, a limited community edition, or a public repository that sits beside the real product while the important parts remain hidden.

Open source is the relationship we want to have with the people who trust Apollo Deploy with their applications.

Deployment platforms operate unusually close to the systems they manage. They receive source code, build applications, store configuration, manage secrets, provision infrastructure, route traffic, observe application health, and initiate recovery actions when something goes wrong.

As these platforms become more autonomous, their responsibility becomes even greater.

A platform that can deploy an application may eventually be able to detect a failure, prepare a recovery plan, shift traffic to a healthy version, scale resources, or roll back a release before a person has opened a dashboard.

That level of access should not depend on blind trust.

You should be able to inspect the platform, understand how it reaches a decision, review the permissions it has been given, and verify what it will do before making it part of your operating model.

Apollo Deploy is open source because trust in infrastructure should be earned through evidence.

Infrastructure should be inspectable

Most application platforms ask teams to hand over a significant amount of control.

They may need access to source repositories, container registries, cloud accounts, environment variables, domains, databases, internal networks, deployment credentials, and production telemetry.

That access is often necessary. A deployment platform cannot operate an application without being able to interact with the systems around it.

The problem is not that the platform has access.

The problem is that teams are frequently expected to trust systems they cannot meaningfully inspect.

You may be able to read documentation describing what a platform claims to do, but documentation is not the implementation. You may receive an audit report, but an audit represents a particular scope at a particular point in time. You may have contractual assurances, but a contract does not explain why a deployment was rolled back at 02:14 or which permissions were evaluated before the action occurred.

Infrastructure should be understandable at the level where decisions are made.

With Apollo Deploy, the repository is intended to be part of the product itself.

Teams should be able to inspect how deployments are represented, how plans are produced, how actions are authorised, how health signals are evaluated, how recovery workflows are executed, and how changes are recorded.

The goal is not to require every customer to audit every line of code. Most teams will not, and they should not need to become experts in Apollo Deploy’s internals simply to deploy an API.

The goal is to make inspection possible.

That distinction matters.

A transparent platform can be reviewed by customers, contributors, security researchers, infrastructure teams, and independent experts. Problems can be discussed against the actual implementation rather than assumptions about a closed system.

Open source turns trust from a promise into something that can be tested.

The repository is part of the product

Some companies publish a repository because open source is useful for distribution, while keeping the production control plane, orchestration logic, policy engine, or operational intelligence private.

That creates an open-source deployment method, but not necessarily an open deployment platform.

Apollo Deploy is being built around a different idea: the operating model itself should be visible.

That includes the components responsible for understanding application state, preparing deployment plans, evaluating permissions, coordinating actions, observing results, and recording what happened.

There may still be commercial services around the platform. Apollo Cloud, managed infrastructure, enterprise support, hosted observability, advanced organisational controls, and operational assistance all require people, hardware, security work, and ongoing investment.

However, the existence of a commercial business should not require hiding the foundation customers depend on.

We want the open repository and the managed product to move in the same direction.

The repository should not be an abandoned approximation of Apollo Cloud. It should not exist only to attract users into a proprietary product. It should remain a practical way to understand, extend, and operate Apollo Deploy.

That creates a harder standard for us, which is precisely the point.

When the implementation is public, architectural shortcuts are visible. Permission boundaries can be questioned. Recovery behaviour can be tested. Decisions require clearer reasoning because contributors and users can challenge them.

Open development creates accountability before a platform ever reaches a customer’s production environment.

What open source means in practice

Open source should create practical freedom, not merely theoretical access to code.

For Apollo Deploy, that freedom is intended to cover four important areas.

Inspect the implementation

Teams should be able to understand how the platform works before granting it access to important systems.

That includes reviewing:

• How application and infrastructure state are represented.
• How deployment plans are generated.
• How permissions and policies are evaluated.
• How secrets and credentials are handled.
• How build and release processes are executed.
• How health signals influence operational decisions.
• How rollback and recovery actions are triggered.
• How agent actions are constrained.
• How every important operation is recorded for later review.

The objective is not transparency for its own sake. It is to make operational behaviour explainable.

When a deployment fails, a team should not receive only a generic error message. The platform should expose the plan, the action that failed, the state it expected, the state it observed, and the effect of any recovery attempt.

When an automated action succeeds, the same standard should apply. Successful automation should still be explainable.

Extend the platform

No deployment platform can anticipate every infrastructure environment, internal policy, data boundary, or operational workflow.

A financial institution may require deployments to pass through an internal approval system. A healthcare company may need workloads to remain within a specific region. A small development team may want to connect Apollo Deploy to a self-hosted Git service and an existing observability stack. Another team may need a custom recovery workflow for specialised hardware or edge infrastructure.

Those requirements should not always depend on Apollo Deploy officially supporting every possible integration.

An open platform gives teams the ability to build:

• Custom deployment sources.
• Infrastructure providers.
• Build strategies.
• Health checks.
• Policy rules.
• Approval workflows.
• Notification channels.
• Observability integrations.
• Recovery actions.
• Agent tools.
• Internal plugins and operational extensions.

Extensions should integrate with the same planning, permission, execution, and audit model as the rest of the platform.

That is important because custom functionality should not require bypassing the safety model.

The aim is not to create a collection of scripts with unrestricted infrastructure access. It is to give teams a structured way to add capabilities while preserving review, permissions, and accountability.

Run it where it fits

Some teams want a fully managed platform. They do not want to operate a control plane, maintain deployment workers, manage updates, or investigate the strange collection of networking decisions that modern infrastructure has somehow convinced everyone are normal.

For those teams, Apollo Cloud will provide a managed experience.

Other teams need to keep workloads on infrastructure they control. They may have regulatory requirements, data-residency obligations, existing hardware, private networks, predictable infrastructure commitments, or security policies that prevent an external platform from directly operating production systems.

Those teams should be able to self-host Apollo Deploy.

A third group may need both.

They may use Apollo Cloud for public applications while keeping sensitive services on private infrastructure. They may run the control plane themselves while using selected managed services. They may operate across cloud providers, bare-metal servers, regional infrastructure, and edge environments.

Apollo Deploy should support that reality without forcing every workload into one vendor’s preferred environment.

The same operating concepts should apply whether an application runs on Apollo Cloud, a customer-managed server, a private cluster, or a supported external infrastructure provider.

Teams should not need to relearn deployment, policy, and recovery concepts each time the underlying environment changes.

Keep your options open

Infrastructure decisions have long consequences.

Applications often remain in production much longer than expected. Teams change. Companies are acquired. Prices increase. Products are discontinued. Compliance requirements evolve. A provider that once matched a company’s needs may no longer fit several years later.

A team should be able to adapt without rebuilding its entire operating model from the beginning.

Open source helps protect that option.

It allows teams to continue operating the software, maintain an internal version, contribute required capabilities, migrate infrastructure, or work with another provider without waiting for a vendor to approve the direction.

This does not make migration effortless. Infrastructure is still infrastructure, and humanity has not yet discovered a licence that makes distributed systems stop being distributed systems.

It does, however, prevent the platform itself from becoming an artificial barrier.

Open source reduces platform risk

Vendor lock-in is often discussed only as a pricing problem.

Pricing matters, but lock-in has broader consequences.

A proprietary platform may accumulate knowledge about an application that is difficult to reproduce elsewhere. Deployment configuration, environment behaviour, routing rules, operational history, scaling decisions, and recovery workflows can become deeply tied to the provider’s internal model.

Over time, leaving becomes less about moving containers and more about reconstructing how the application was operated.

Apollo Deploy aims to keep that operating model explicit.

Deployment plans, application definitions, policies, environment configuration, operational events, and recovery actions should be represented in ways teams can understand and export.

The objective is not to pretend that every infrastructure provider is interchangeable. They are not. Different environments expose different capabilities, failure modes, and pricing structures.

The objective is to ensure that Apollo Deploy does not intentionally make those differences harder to navigate.

An open operating layer gives teams a better chance of preserving their knowledge as infrastructure changes underneath them.

A better boundary for AI agents

AI agents make it possible to hand off more of the work involved in deploying and operating applications.

An agent can inspect a repository, review deployment state, identify a configuration issue, prepare a release, investigate an unhealthy service, or recommend a recovery action faster than a person manually moving between dashboards.

The danger appears when convenience is achieved by giving the agent unrestricted access.

An agent should not need a permanent administrator key to every system surrounding an application. It should not be able to improvise arbitrary production changes merely because it received a broad instruction such as “fix the deployment.”

Useful autonomy requires boundaries.

Apollo Deploy is being designed around a plan-and-apply operating model.

Instead of allowing an agent to immediately perform an unrestricted series of actions, the platform can separate the operation into explicit stages.

1. Inspect

The agent or human inspects the current state of the application.

This may include:

• The active release.
• Recent deployments.
• Application health.
• Logs and error signals.
• Resource utilisation.
• Routing state.
• Infrastructure availability.
• Policy requirements.
• Previous recovery attempts.

Inspection should use scoped platform capabilities rather than unrestricted access to every underlying system.

2. Plan

Apollo Deploy produces or validates a structured plan describing the intended change.

The plan should explain:

• What will change.
• Why the change is being proposed.
• Which resources will be affected.
• Which permissions are required.
• What risks have been identified.
• What checks must pass before execution.
• What rollback or recovery options are available.
• Whether human approval is required.

The plan becomes the shared contract between the person, the agent, and the platform.

3. Authorise

The platform evaluates whether the proposed operation is allowed.

Authorisation may depend on:

• The identity requesting the action.
• The environment being changed.
• The application’s policy.
• The risk level of the operation.
• The time of day.
• The affected infrastructure.
• The presence of required approvals.
• The health of related services.
• Organisational rules.
• Temporary access grants.

An agent may be allowed to restart a failed development service automatically while requiring approval before changing production traffic.

A team may permit automated rollback to a previously verified release but prevent an agent from introducing a new infrastructure dependency without review.

Autonomy does not need to be all or nothing.

4. Apply

Once authorised, the platform executes the approved plan.

Execution should remain constrained to the operations included in that plan. If the environment changes materially while the plan is being applied, Apollo Deploy should be able to stop, re-evaluate, or request a new plan rather than blindly continuing.

That helps prevent a valid plan from becoming unsafe because its assumptions are no longer true.

5. Observe

After execution, Apollo Deploy observes the result.

A deployment is not successful merely because a process returned a successful status code. The platform should evaluate whether the application reached the expected state.

That may include checking:

• Service health.
• Error rates.
• Response latency.
• Resource behaviour.
• Dependency availability.
• Traffic distribution.
• Deployment-specific signals.
• Application-defined success criteria.

6. Record

The platform records the operation in an audit trail.

Teams should be able to see:

• Who or what initiated the operation.
• The state observed before the action.
• The plan that was approved.
• The permissions that were evaluated.
• The changes that were applied.
• The signals observed afterward.
• Any recovery action that followed.
• The final result.

This creates a common operational language for humans, command-line tools, CI systems, and AI agents.

They can all use the same planning and permission model rather than creating a separate, less controlled path for automation.

Why openness matters more when agents are involved

Closed automation requires teams to trust both the outcome and the hidden reasoning of the system providing it.

Open infrastructure does not make AI agents infallible. It does make the boundaries around them easier to evaluate.

Teams can inspect which tools are exposed to an agent. They can review how actions are scoped. They can test policy behaviour. They can reproduce a plan. They can contribute safeguards. They can identify situations where the platform is granting more authority than necessary.

This creates a healthier division of responsibility.

The agent can help understand intent and propose useful action. Apollo Deploy can provide deterministic infrastructure capabilities, policy enforcement, execution controls, and auditability.

The agent does not need to become the infrastructure platform.

It operates through the platform.

That distinction is central to the way Apollo Deploy approaches autonomous operations.

The same platform for humans, CLIs, and agents

Many platforms treat automation as an additional interface layered on top of a product designed primarily for dashboards.

Apollo Deploy is being designed so that humans, command-line tools, APIs, CI systems, and AI agents use the same underlying operating model.

A deployment created from the dashboard should produce the same type of plan as a deployment initiated from the CLI.

An operation requested by an agent should pass through the same permission system as an operation requested by a person.

A recovery action triggered automatically should appear in the same operational history as a manual rollback.

This consistency reduces ambiguity.

Teams should not need separate security models for each interface. They should not need to wonder whether an AI integration bypasses the approval process used by the dashboard. They should not have to reconstruct activity across several disconnected audit systems.

Every interface should ultimately interact with the same controlled capabilities.

Security improves when assumptions can be challenged

Open-source software is not automatically secure.

Publishing code does not remove vulnerabilities, eliminate configuration mistakes, or guarantee that every contributor has made the correct decision.

What open source changes is the ability to examine those decisions.

Security researchers can review implementation details. Customers can assess whether the permission model matches their requirements. Contributors can propose stronger defaults. Teams can test the platform in environments that the original developers may not have anticipated.

Security discussions can refer to actual code and reproducible behaviour.

Apollo Deploy must still maintain a serious security process around:

• Dependency management.
• Vulnerability disclosure.
• Secret handling.
• Authentication.
• Authorisation.
• Tenant isolation.
• Build isolation.
• Network boundaries.
• Supply-chain security.
• Release signing.
• Audit integrity.
• Infrastructure hardening.
• Secure defaults.

Open development does not replace that work.

It makes the work visible and gives more people the opportunity to improve it.

Self-hosting should be a real operating option

Self-hosting is sometimes offered as a technical possibility without being treated as a practical product.

The code may be available, but installation is poorly documented. Updates are fragile. Important operational features depend on private services. The self-hosted version receives fixes slowly or lacks the capabilities required for serious use.

Apollo Deploy should not call itself self-hostable merely because someone can eventually persuade the repository to start after a weekend of examining environment variables.

Self-hosting should be intentionally supported.

That means working toward:

• Clear installation documentation.
• Reproducible releases.
• Explicit infrastructure requirements.
• Supported upgrade paths.
• Configuration validation.
• Backup and recovery guidance.
• Observable system health.
• Migration tools.
• Secure defaults.
• Compatibility information.
• A clear distinction between community and commercially supported deployments.

Self-hosting will still require operational knowledge. Running an application platform means running databases, workers, networking components, build infrastructure, and other services that are stubbornly unaffected by inspirational homepage copy.

The objective is not to pretend those responsibilities disappear.

The objective is to make them understandable and manageable.

Apollo Cloud exists to remove operational burden

Open source and managed cloud are not opposing ideas.

Apollo Cloud will exist for teams that want the capabilities of Apollo Deploy without operating the platform itself.

A managed service can provide value through:

• Hosted control-plane infrastructure.
• Managed platform updates.
• Build execution.
• Application runtime infrastructure.
• Networking and routing.
• Certificates and domains.
• Monitoring and operational telemetry.
• Backups.
• Platform availability.
• Security maintenance.
• Regional deployment options.
• Support.
• Managed integrations.
• Capacity planning.
• Incident response.

Customers should pay Apollo Cloud for infrastructure, reliability, convenience, support, and managed operations.

They should not be forced to pay merely to understand how their deployment platform works.

How Apollo Deploy plans to make money

Open source does not mean there is no business.

It means the business must provide value beyond restricting access to the software.

Apollo Deploy plans to build a sustainable company around several commercial offerings.

Managed application hosting

Teams using Apollo Cloud will pay for the infrastructure consumed by their applications.

Depending on the final platform design, usage may include:

• Compute.
• Memory.
• Build time.
• Storage.
• Network transfer.
• Databases or managed data services.
• Dedicated infrastructure.
• Regional capacity.
• Additional operational services.

Usage-based pricing makes the relationship clearer: customers pay for resources and managed capabilities they use.

Managed control plane

Some teams may want to run applications on their own infrastructure while allowing Apollo Deploy to manage the control plane.

This model can reduce the burden of maintaining the platform while keeping workloads and sensitive data within customer-controlled environments.

The managed control plane may include hosted coordination, updates, audit storage, policy management, agent integrations, and operational visibility.

Team and organisational capabilities

Larger teams require more than the ability to start a deployment.

Commercial organisational capabilities may include:

• Advanced role-based access control.
• Approval workflows.
• Central policy management.
• Extended audit retention.
• Single sign-on.
• Directory synchronisation.
• Environment-level restrictions.
• Compliance exports.
• Organisation-wide observability.
• Advanced cost controls.
• Dedicated support.
• Service-level agreements.

These features support coordination, governance, and accountability across larger organisations.

They should not exist merely to make the open-source product intentionally difficult to use.

Enterprise support

Companies running critical workloads may need direct assistance.

Enterprise support may include:

• Deployment architecture reviews.
• Self-hosting assistance.
• Upgrade planning.
• Security guidance.
• Priority incident support.
• Custom integrations.
• Migration assistance.
• Dedicated communication channels.
• Long-term support arrangements.
• Training for platform and infrastructure teams.

The value is access to expertise and operational support, not permission to use the underlying ideas.

Pricing principles

Final Apollo Cloud pricing will be published before the service becomes generally available. The exact amounts will depend on the infrastructure model, supported regions, runtime architecture, and the real cost of operating the platform.

The principles can be defined before the final numbers.

The open-source platform should remain usable without a subscription

Teams should be able to inspect, run, modify, and contribute to the open-source platform under its published licence.

Apollo Deploy should not require a recurring software subscription merely to operate the open-source version on infrastructure a team already owns.

Customers will still be responsible for their own servers, networking, storage, databases, backups, security, and operational work. Open-source software does not persuade electricity providers to stop sending invoices.

The distinction is that Apollo Deploy will not add an artificial platform fee simply because the team chose to operate the software itself.

Apollo Cloud should charge for managed value

Apollo Cloud pricing should reflect the infrastructure and operational work Apollo Deploy provides.

That may include a combination of:

• A free allowance for experimentation.
• Predictable base plans for individuals and teams.
• Usage-based infrastructure charges.
• Optional managed services.
• Enterprise agreements for dedicated requirements.

The objective is to make it possible to begin with a small application and grow without facing an immediate wall of enterprise pricing.

Pricing should be understandable

Teams should be able to estimate the cost of running an application before deploying it.

Pricing should avoid unnecessary layers of abstract units that make a calculator feel like a forensic investigation.

Where costs depend on usage, Apollo Deploy should explain which resources are being measured, how they are measured, and how teams can control them.

The platform should provide:

• Usage visibility.
• Cost estimates.
• Budget limits.
• Alerts.
• Resource-level breakdowns.
• Historical cost information.
• Clear descriptions of additional charges.

Autonomous infrastructure should not autonomously create a finance incident.

The platform should not punish portability

Apollo Deploy should not use data export fees, proprietary configuration formats, or artificial restrictions to make leaving the platform unnecessarily expensive.

Underlying infrastructure providers may still charge for network transfer and other resources. Those costs cannot always be removed.

Apollo Deploy’s own product design should not intentionally make migration more difficult.

Commercial features should solve commercial problems

Paid features should deliver additional operational value.

Examples include managed availability, advanced organisational controls, compliance support, dedicated infrastructure, longer data retention, and priority support.

The open-source product should not be broken apart merely to move basic deployment functionality behind a payment screen.

A possible product structure

The final packages may change as Apollo Deploy develops, but the intended structure is straightforward.

Apollo Deploy Community

Price: Free and open source.

Designed for developers and teams that want to run Apollo Deploy on their own infrastructure.

The community product is expected to include the core operating platform required to:

• Connect applications.
• Prepare and execute deployments.
• Manage environments.
• Apply permissions.
• Record operational activity.
• Run supported integrations.
• Use the API and CLI.
• Integrate with agent workflows.
• Operate supported workloads on customer-managed infrastructure.

Customers provide and operate the required infrastructure.

Community support will happen through public documentation, repository discussions, issues, and community channels.

Apollo Cloud

Price: Managed plans plus infrastructure usage.

Designed for teams that want Apollo Deploy to operate the platform and, where selected, the infrastructure running their applications.

Apollo Cloud is expected to provide:

• Managed platform hosting.
• Automated updates.
• Hosted builds.
• Managed networking.
• Application runtime resources.
• Operational monitoring.
• Managed certificates.
• Integrated logs and deployment history.
• Team collaboration.
• Usage and cost controls.
• Cloud support.

Small projects should be able to begin with a low-cost or free allowance. Growing applications will pay according to the resources and managed services they consume.

Apollo Deploy Enterprise

Price: Based on infrastructure, support, security, and organisational requirements.

Designed for organisations with advanced governance, compliance, networking, support, or deployment requirements.

Enterprise agreements may include:

• Dedicated infrastructure.
• Private networking.
• Advanced identity integration.
• Organisation-wide policy controls.
• Extended audit retention.
• Compliance assistance.
• Guaranteed support response times.
• Architecture and migration support.
• Managed self-hosted deployments.
• Custom integrations.
• Regional or data-residency commitments.

Enterprise pricing should correspond to actual enterprise requirements, not simply the presence of more than a few users.

What Apollo Deploy aims to accomplish

Open source is a means, not the final outcome.

The goal is to create a better operating layer for applications.

Make application operations understandable

Teams should be able to understand what is running, what changed, why it changed, and what the platform did in response.

Operational knowledge should not remain trapped inside one person’s memory, an undocumented script, or a collection of provider-specific dashboards.

Make safe automation practical

Automation should move beyond isolated CI scripts while remaining controlled.

Apollo Deploy aims to provide a structured environment where humans and agents can inspect state, prepare plans, operate within permissions, and verify results.

Reduce the amount of repetitive operational work

Developers should spend less time manually coordinating deployments, checking routine failures, comparing dashboards, and performing predictable recovery actions.

The platform should handle repetitive work while escalating decisions that require human judgement.

Preserve human control

Autonomy should not remove accountability.

Teams should decide which operations may happen automatically, which require approval, and which must never be performed by an agent.

The platform should make those boundaries explicit and enforceable.

Support more than one infrastructure model

Teams should be able to use Apollo Cloud, self-host the platform, run workloads on their own infrastructure, or combine managed and private environments.

Infrastructure choice should not require abandoning the operating model.

Build a shared ecosystem

An open platform allows integrations, providers, policies, workflows, and operational capabilities to be developed by more than one company.

A contributor should be able to add support for infrastructure Apollo Deploy does not operate. A team should be able to publish a deployment workflow for a specialised environment. A provider should be able to integrate its services without waiting for Apollo Deploy to prioritise the work internally.

That creates a broader foundation than any closed roadmap can provide.

What open source does not mean

Open source does not mean every proposed feature will be accepted.

The platform still needs a coherent architecture, security model, contribution process, and long-term direction.

It does not mean production support is free.

Community support and commercial support solve different problems. Organisations that need guaranteed response times, implementation assistance, or contractual commitments should expect to pay for those services.

It does not mean self-hosting has no cost.

Teams running Apollo Deploy themselves will pay for infrastructure and carry the responsibility of operating it.

It does not mean every operational decision will be made by public vote.

Apollo Deploy will maintain a clear product direction. Community feedback should influence that direction without turning architecture into a competition between whichever feature request collected the most reaction emojis.

Open source means the implementation can be inspected, used according to its licence, discussed, improved, extended, and contributed to in public.

It means important decisions require explanation.

It means the platform must earn adoption rather than depend entirely on captivity.

Building in public creates better questions

A closed product conversation often begins with:

What will the vendor allow us to do?

An open product conversation can begin with:

What should this platform make possible?

That leads to better questions.

How should agents receive temporary authority?

Which recovery actions are safe to automate?

How should a deployment plan represent risk?

What evidence should be required before production traffic moves?

How can teams preserve operational history across infrastructure providers?

Which parts of an application’s operating model should remain portable?

How can contributors add capabilities without weakening the permission boundary?

These are not questions Apollo Deploy should answer alone.

Application operations affect developers, infrastructure engineers, security teams, platform teams, open-source maintainers, and the people responsible for recovering systems when every optimistic assumption has finally encountered production.

Building in the open allows those perspectives to shape the platform earlier.

Trust must survive success

It is relatively easy for an early project to appear open.

The real test comes later.

It comes when managed cloud revenue grows. It comes when enterprise customers request private capabilities. It comes when maintaining the public repository becomes inconvenient. It comes when hiding an important component might create a temporary commercial advantage.

Apollo Deploy’s commitment to open source matters only if it survives those pressures.

That requires treating openness as a product constraint from the beginning.

The company should grow by making Apollo Cloud easier to operate, more reliable, more secure, and more useful than running everything yourself.

It should grow through support, managed infrastructure, organisational capabilities, and operational expertise.

It should not need to make the open platform deliberately worse.

That is a more demanding business model, but it creates a healthier relationship.

Customers remain because the product continues to provide value, not because leaving has been made artificially painful.

Build the operating layer together

The infrastructure running an application should never become another locked door.

Teams should be able to understand the platform responsible for their deployments. They should be able to inspect its permissions, review its actions, extend its capabilities, and run it in the environment that matches their requirements.

AI agents make that transparency more important, not less.

As agents take on more operational work, the platform around them must provide stronger plans, clearer boundaries, deterministic capabilities, and complete records of what happened.

Apollo Deploy is being built to become that operating layer.

A platform for humans, command-line tools, continuous integration systems, and AI agents.

A platform that can run on your infrastructure or in Apollo Cloud.

A platform where deployment, recovery, and infrastructure operations can become increasingly autonomous without becoming unaccountable.

Open source is how we intend to earn the trust required to build it.

Start with the repository. Inspect the implementation. Read the decisions. Challenge the assumptions. Contribute an integration, propose a policy, report a problem, or help improve the operating model.

Apollo Deploy is being built in the open because the future of application operations should not be decided behind a locked door.