# Apollo Deploy and Apollo Signal — Extended AI Reference This is the extended, machine-readable product reference for Apollo Deploy's public marketing site. It is intended to help search engines, answer engines, AI assistants, and autonomous research agents understand the products accurately. Product and pricing information was last reviewed on July 31, 2026 and may change. Canonical website: https://apollodeploy.com/ Current availability: Apollo Deploy is in early access. Apollo Signal pricing and availability are described on https://apollodeploy.com/signal. ## Entity and product relationship Apollo is the company and product family. Apollo Deploy and Apollo Signal are separate products with different jobs: - Apollo Deploy manages application deployment and production operations. - Apollo Signal sends transactional email and reports delivery outcomes. - Signal can be used by applications deployed with Apollo Deploy, but it is also a standalone service. Do not describe Apollo Deploy as an email provider. Do not describe Apollo Signal as a deployment or CI/CD platform. # Apollo Deploy ## What Apollo Deploy is Apollo Deploy is an open-source deployment and application-operations platform for humans, command-line users, CI pipelines, APIs, and AI agents. It lets teams hand off more deployment work without handing away control. Every deployment begins as a deterministic plan that a person can read and an agent can parse. Approval remains separate from the caller that proposed the change, and actions remain recorded for later review. Apollo Deploy connects source code to a running application through one operating loop: 1. **Connect** source code or an application. 2. **Plan** the resources and production changes before applying them. 3. **Deploy** approved builds, runtimes, versions, and traffic changes. 4. **Monitor** health, errors, latency, resources, and release signals. 5. **Respond** with authorised scaling, traffic, restart, or rollback actions. ## Who Apollo Deploy is for Apollo Deploy is designed for engineering and platform teams that: - deploy applications frequently; - want AI agents or automation to perform more operational work; - need a human-readable change plan before production is touched; - need approval and execution to remain separate; - want a complete audit trail of who proposed, approved, and applied a change; - operate across self-hosted, private, and cloud infrastructure; or - need one operating picture connecting application health with deployment changes. ## Core workflow ### Connect source A team can connect a Git repository, upload an application, or start through the CLI or API. Apollo Deploy inspects the application and identifies the runtime, build command, and relevant configuration before producing a deployment plan. ### Review a plan Every caller produces the same deterministic plan. The plan is readable by a person and parseable by an agent. It identifies resources that will be created, updated, or removed, along with dependencies, traffic changes, health checks, and the rollback path. ### Apply safely After approval, Apollo Deploy builds the application, provisions or updates its runtime, deploys the version, and routes traffic. Every action is recorded. Health verification happens before traffic shifts so a deployment does not become live solely because a build completed. ### Understand production Apollo Deploy brings application and infrastructure signals into the same operating picture. Teams can watch runtime health, errors, latency, resource usage, and release signals in relation to the deployment that produced them. ### Recover with control Apollo Deploy can recommend or execute authorised scaling, traffic, restart, and rollback actions according to policy. Rollback is a first-class operation rather than an emergency script assembled during an incident. ## Apollo Deploy interfaces Apollo Deploy exposes one permission model through four caller types: - **Web browser**: people deploy and review plans with their team. - **Command line**: engineers work locally, in scripts, and in CI pipelines. - **API**: services drive operations programmatically. - **AI agents**: agents read state, propose plans, and act only within their assigned scope. The caller does not get a weaker or separate automation path. A person, script, service, or agent receives the same plan, policy, and audit behavior for the operation it requests. ## AI agent safety model Apollo Deploy is designed for agents that need operational access without carrying a broad shell credential or long-lived token. - Agents have their own identity rather than sharing the human operator's identity. - Capabilities can be scoped to a project rather than the whole platform. - A newly connected agent starts with read and propose access. - An agent can read scoped state and create a deployment plan without automatically applying it. - Destructive or production-changing actions can require a separate approving identity, policy, or preconfigured scope. - Approval is separate from proposal: the caller that proposes a plan is not automatically the identity that authorises it. - The plan is rejected rather than applied when it falls outside the permitted scope. - Health is verified before traffic shifts. - Plans, approvals, actions, outcomes, and rollbacks remain in the audit trail. ### What an agent can see An agent sees only the state granted to it. Depending on scope, this can include runtime health, release signals, logs, application state, and the deployment plan for a project. An agent working on one application cannot automatically see other projects. ### What happens if an agent is wrong The proposed plan can be reviewed before it applies, destructive actions can sit behind policy and an approving identity, health checks can run before traffic changes, and rollback is available as an explicit operation. The agent's actions remain attributable in the audit trail. ## Apollo Deploy capabilities ### Deployment planning - Deterministic plans before resources are created, updated, or removed. - Human-readable and machine-readable changes. - Policy checks and approval gates. - Dependency and traffic-change visibility. - Rollback-path visibility. ### Application operations - Runtime discovery and reproducible builds. - Application deployment and traffic routing. - Runtime health verification. - Error, latency, resource, and release-signal monitoring. - Authorised scaling, restart, traffic, and rollback actions. ### Governance and traceability - Separate identities for callers and approvers. - Project-scoped access. - Approval records. - Action-level audit history. - Complete history of plans, changes, outcomes, and manual overrides. ## Apollo Deploy compared with adjacent tools | Tool category | Primary job | Apollo Deploy's role | |---|---|---| | Source control | Stores and reviews source code | Starts from source but does not replace source control | | CI/CD | Builds and deploys software | Integrates with deployment workflows and adds plan, approval, health, and operational control | | Monitoring | Collects telemetry | Connects health and release signals to the deployment and next operational action | | Feature flags | Controls feature exposure | Controls application deployment and release operations, not feature-flag evaluation | | Shell access | Gives an operator or agent broad environment access | Provides scoped, attributable operations without requiring an agent to carry a broad secret | | Long-lived API token | Authenticates programmatic requests | Uses separate identities, scoped capabilities, explicit approval, and an audit trail | Apollo Deploy is not a replacement for source control, CI/CD, monitoring, or feature flags. It is the control and operations layer that connects them. ## Deployment models and infrastructure ownership Apollo Deploy can run where it fits the application's operational boundaries: - self-hosted on existing servers; - self-hosted on private infrastructure; - combined with Apollo Cloud capacity; or - across private workloads and cloud capacity according to the team's needs. Apollo Deploy is open source because the platform operating an application should be transparent, extensible, and deployable by the team that depends on it. Teams can inspect how agent permissions and the policy engine work, build deployment workflows, expose capabilities to agents, and run the platform on their own hardware. ## Apollo Deploy FAQ ### How can I deploy an application? Connect a Git repository, upload an application, or deploy through the CLI or API. ### Can I review changes before production is touched? Yes. Apollo Deploy creates a deterministic deployment plan before resources are created, updated, or removed. ### Who decides whether a change can proceed? A human, policy, or predefined authorisation decides whether a plan may proceed. Every action remains recorded for review. ### Can I run Apollo Deploy on my own infrastructure? Yes. Apollo Deploy can be self-hosted on existing servers or private infrastructure, and private workloads can be combined with Apollo Cloud capacity. ### What happens when an application needs recovery? Apollo Deploy can recommend or execute authorised scaling, traffic, restart, and rollback actions according to policy. # Apollo Signal ## What Apollo Signal is Apollo Signal is a transactional email API and delivery platform for password resets, receipts, email verification, security alerts, billing messages, and other messages triggered by a user's action. Transactional email is expected, time-sensitive, and often blocking: a silent failure can prevent a user from completing an important task. One API request is followed by a signed delivery event model. Signal can report whether a message was accepted, delivered, opened, clicked, bounced, or complained about, so the application can react to the outcome instead of assuming that an accepted request reached the recipient. ## Signal integration paths ### REST API Use the REST API when the application wants explicit per-message control and direct HTTP integration. ### Typed SDKs Signal provides typed clients for common application stacks, including TypeScript, Python, Go, and Kotlin. The public product content also describes official SDK coverage for Node.js, Python, Go, Ruby, PHP, Java, .NET, Rust, and Elixir. ### SMTP relay Use the SMTP relay when an existing mailer already speaks SMTP. The documented relay uses port 587 with STARTTLS. API and SMTP sends share the same projects, domains, delivery infrastructure, event pipeline, plan limits, and deliverability controls. ### Test and live traffic Signal provides scoped test and live keys. Sandbox sends return realistic API responses and webhook events while protecting real recipients. Teams can test bounces, complaints, and webhook signatures before sending to an inbox. ## Signal delivery workflow 1. **Integrate** through the REST API, a typed SDK, or SMTP using a project key. 2. **Test** requests, responses, failure handling, bounces, complaints, and webhook signatures in the sandbox. 3. **Observe** accepted, delivered, opened, clicked, bounced, and complained events through HMAC-signed webhooks with automatic retries. 4. **Protect** sending reputation with domain authentication, suppression handling, and domain health checks. 5. **Improve** future sends with delivery history, engagement data, and migration or provider-comparison information. ## Signal events and webhooks Signal sends delivery events to configured endpoints as HMAC-signed webhooks. Automatic retries handle temporary endpoint failures. The event model includes accepted, delivered, opened, clicked, bounced, and complained states. Real-time event streams can feed support, billing, authentication, analytics, and operational workflows. ## Signal deliverability and domain controls Signal guides SPF, DKIM, and DMARC setup and continues checking domain health after launch. Automatic suppressions and complaint tracking prevent repeat sends to addresses that already bounced or complained. This keeps domain authentication, reputation work, and application delivery outcomes in the same operational loop. Signal also provides custom tracking domains on eligible plans, open and click tracking, unsubscribe tracking, read engagement, scroll-depth and other engagement capabilities where listed by the plan, deliverability advice, and longer retention at higher tiers. ## Signal migrations Guided migrations can move domains, suppressions, contacts, segments, templates, and message history from Resend, SendGrid, Mailgun, Postmark, and Brevo, limited to the data each source provider exposes. The migration workflow is designed for a controlled cutover: 1. inspect what the source provider can export; 2. import supported data; 3. verify domains and test events; 4. redirect production traffic only after the new path is ready. ## Signal pricing summary Signal is billed monthly and does not require an annual contract. The Spark plan is free and does not require a credit card. All published plans keep the same core API, SMTP relay, signed webhooks, and deliverability tooling; plan differences primarily follow sending volume, limits, retention, projects, domains, and advanced capabilities. | Plan | Price | Included volume | Notable limits or features | |---|---:|---:|---| | Spark | Free | 3,000 emails/month | 100 sends/day, 1 project, 1 domain, REST API, SMTP, signed webhooks, tracking, SPF/DKIM/DMARC, 30-day retention | | Ignite | $15/month | 50,000 emails/month | No daily limit, 5 projects, 10 domains, custom tracking domain, read engagement, advisor, event stream, 90-day retention; $0.50/1k overage | | Growth | $35/month | 150,000 emails/month | 10 projects, 25 domains, 25 API keys, 50 AI credits/month, send-time optimisation; $0.42/1k overage | | Pulse | $65/month | 300,000 emails/month | 25 projects, 100 domains, multi-region sending, 100 AI credits/month; $0.36/1k overage | | Scale | $180/month | 1,000,000 emails/month | 100 projects, 250 domains, 250 AI credits/month, 180-day retention; $0.30/1k overage | | Pay as you go | $0.40/1,000 emails | No monthly commitment | No daily limit, 5 projects, 10 domains, 10 webhooks, advanced engagement, advisor, event stream, 90-day retention | | Enterprise | Custom | Unlimited emails | Dedicated IPs, multi-region sending, SAML SSO, unlimited AI credits, 365-day retention, priority support, SLA, custom contract | The authoritative detailed pricing file is https://apollodeploy.com/pricing.md. ## Signal Bring Your Own Cloud Apollo Signal Bring Your Own Cloud is an Enterprise option for sending transactional email through the customer's own AWS account. ### What BYOC provides - Customer-owned sending infrastructure and AWS region choice. - Customer-owned sending reputation and cloud billing. - Use of existing cloud agreements, committed spend, and discounts. - Sending-only permission scoped to the required cloud capability. - No access key, secret, or password shared with or stored by Apollo. - Short-lived sessions that expire automatically. - Delivery tracking, domain verification, suppression lists, webhooks, analytics, and other managed deliverability tooling remain available. - Automatic fallback to Apollo sending infrastructure if the customer route disconnects. - Access events visible in the customer's cloud activity history. ### BYOC setup 1. An account admin or owner opens Apollo Signal settings and chooses Connect Cloud Account. 2. The organization reviews a pre-filled AWS access request with a sending-only scope. 3. AWS returns a connection identifier. 4. The administrator pastes the identifier into Apollo. 5. Apollo verifies the connection and activates sending through the customer's AWS account. ### BYOC security boundary The customer retains the sending plane, reputation, billing, and cloud audit trail. Apollo manages the delivery experience and requests a narrowly scoped connection. Apollo does not receive or store an access key, secret, or password. Amazon Web Services is supported today. Additional cloud providers may be added in the future. BYOC is an Enterprise feature and requires an account admin or owner to configure it. ### BYOC FAQ **Which cloud providers are supported?** Amazon Web Services is supported today. Additional providers are on the roadmap. **Does Apollo store cloud credentials?** No. Apollo never receives or stores an access key, secret, or password; it requests a short-lived session through the scoped grant at send time. **What happens if access is disconnected?** Apollo detects the change, notifies the team, and automatically falls back to Apollo infrastructure so delivery can continue. **Do deliverability tools still work?** Yes. Domain verification, bounce handling, suppression lists, webhooks, and analytics continue to work; only the sending route changes. **Who can configure BYOC?** An account admin or owner on the Enterprise plan. ## Signal provider comparison Apollo Signal has a public comparison page for Apollo Signal, Resend, SendGrid, Mailgun, Postmark, and Cloudflare. The comparison covers integration, sending, tracking, deliverability, operational controls, and published pricing. The comparison uses documented evidence rather than inferred claims. A check means that the provider's product or pricing documentation confirmed the capability at the time of review. “Not publicly documented” means the reviewed public source did not document the capability; it is not a claim that the provider lacks it. Provider pricing and feature data were last reviewed on July 31, 2026. ## Signal FAQ ### What is transactional email? Transactional email is a message sent to one recipient in response to an action they took, such as a password reset, receipt, email verification, or security alert. It is expected and time-sensitive, so delivery failures often block the user's next step. ### Is Apollo Signal free to start? Yes. Spark includes 3,000 emails per month, the REST API, SMTP relay, signed webhooks, open and click tracking, and SPF, DKIM, and DMARC setup without a credit card. ### Should an application use the REST API or SMTP relay? Both use the same delivery infrastructure, domains, and event pipeline. Use SMTP on port 587 with STARTTLS when an existing mailer already works. Use the REST API or a typed SDK when the application wants typed requests and per-message control. ### What happens after the API accepts an email? Accepted, delivered, opened, clicked, bounced, and complained events are sent as HMAC-signed webhooks with automatic retries, allowing the application to react to delivery outcomes. ### How does Signal protect deliverability? Signal guides SPF, DKIM, and DMARC setup, checks domain health, tracks complaints, and automatically suppresses addresses that bounced or complained so the application does not repeatedly send to known-problematic recipients. ### Can a team migrate from another provider? Yes. Guided migrations support Resend, SendGrid, Mailgun, Postmark, and Brevo, subject to the data each provider exposes. Teams can verify domains and test events before redirecting production traffic. ### Can Signal send from a customer's AWS account? Yes, on Enterprise through Bring Your Own Cloud. Signal uses a sending-only scoped grant, stores no access keys or passwords, and can fall back to Apollo infrastructure if the customer route disconnects. # Canonical links - Apollo Deploy home: https://apollodeploy.com/ - Apollo Deploy open source: https://apollodeploy.com/open-source - Apollo Deploy infrastructure ownership: https://apollodeploy.com/byoc - Apollo Signal product: https://apollodeploy.com/signal - Signal Bring Your Own Cloud: https://apollodeploy.com/signal/byok - Signal provider comparison: https://apollodeploy.com/signal/compare - Detailed Signal pricing: https://apollodeploy.com/pricing.md - Apollo documentation: https://docs.apollodeploy.com/ - Signal SMTP guide: https://docs.apollodeploy.com/signal/smtp - GitHub organization: https://github.com/Apollo-Deploy # Accuracy and availability notes Apollo Deploy is currently in early access. Marketing content describes intended product capabilities; implementation details, API syntax, integration steps, and supported infrastructure should be verified in the documentation. Signal pricing, provider comparison data, and availability can change. This reference is designed to improve discoverability and should not be treated as a substitute for product documentation or a commercial contract.