One production path for every engineering team.

One platform.Every workload.

Keep your portal, workflows and product identity. AstroPulse runs deployment, access, lifecycle and operations underneath, for apps and AI workloads in your cloud.

Start freeTalk to sales
Explore Internal Developer Platform examples

One path to production

From your product to your cloud

Your product

payments-api

Astro Platform

Production layer

Your cloud

Production cluster

One governed deployment workflow

Deploy
Apply access
Observe

Container image · Same production contract, different workload

Who it is for

Build your developer experience. Reuse the production foundation.

  • Your teams deploy APIs, background services and models, but each workload seems to need its own production path.
  • Platform owners manage clusters, access, cost visibility and vulnerability findings. Organization editors can deploy and manage applications without cluster-admin access.
  • You are building your own developer product and want to keep your brand, onboarding, UX and workflows while delegating the production machinery.

Not yet

If you only need a single hosted application and do not own its underlying infrastructure, a turnkey PaaS may be a better fit. AstroPulse matters when you are building the platform itself.

One application contract · different environments

The laptop is the same platform.

Register a conformant local cluster and reuse the application contract across environments. Profiles choose the destination; cloud networking, permissions and backing services still differ.

Laptop

kind · 1 node

payments-api

Staging

GKE · europe-west1

payments-api

Production

EKS · eu-west-1

payments-api

one application contract · every environment

Reusable production capabilities

One foundation for all your workloads.

Set standards once for services and model workloads. Teams keep their runtimes while sharing deployment, access and operational controls.

Different sources. One application lifecycle.

Bring a container image, Helm chart, Git-managed YAML or supported model source. AstroPulse uses the same Applications contract to deploy, inspect and manage each workload.

Reference pattern · use Console, CLI, SDKs, API or Nova

Architecture · 01 / Your components

Image, Helm chart or repo
Team profile
Your domain

02 / AstroPulse infrastructure bricks

Profiles + tiers

Where it lands · how big · set once

Ingress + TLS + DNS

Your domain · certificate renews itself

Lifecycle

Versions · rollback · drift detection

Operations

Health · cost · CVEs per application

03 / Your environment

Application deployment with shared controls

First-class platform add-ons

Open source, integrated into your platform.

NGINX, KEDA, KServe and the other supported ecosystem projects aren't just integrations in a list. AstroPulse treats them as managed cluster capabilities with typed configuration, compatibility checks, dependencies, installation, upgrades and health in the same control plane.

Open-source components stay recognizable. AstroPulse supplies the production workflows around them, while your team owns its architecture, product and access decisions.

Explore supported add-ons

MANAGED CLUSTER CAPABILITIES

Traffic and identity

NGINX Ingress · ExternalDNS · cert-manager · Envoy Gateway

Scale and scheduling

Karpenter · KEDA · Kueue

AI workloads

KServe · your own serving runtime

Configure, install, upgrade and inspect

Policy and approvals where applicable

Developer workflow · MCP

Your editor. Your agent. Your platform.

Bring supported production operations into the coding tools your team already uses. Connected agents can inspect infrastructure and request supported operations through AstroPulse MCP, using the same Astro Platform control plane as the Console and CLI. Editor deployment access is currently available on request.

Explore supported workflows in your personal default organization, then configure the organizations and infrastructure your production use case requires. The personal organization has feature limits.

Your team keeps its source code, build pipeline and developer experience. Production changes remain subject to the access controls and approval requirements of their execution path.

Set up editor integration Explore the Python SDK Application CLI reference Read the workflow

EDITOR TO PRODUCTION

01

Your editor and agent

Your repository, your coding workflow

02

AstroPulse MCP

Discover supported infrastructure operations

03

Governed changes

Permissions and applicable approvals

04

Your cloud

Deploy and inspect through Astro Platform

MCP access supports editor-based operations; deployment through Nova Connect currently requires access approval. Prompt to Production is a separate, access-gated preview.

Day 2 · keep it running

A stuck rollout, without the war room.

One application lifecycle, from status and history to supported remediation. Nova can investigate through permitted tools and propose changes for review.

Rollout

Status and the reason, in words

Lifecycle

History, resync and rollback

Cost

Allocation and usage when enabled

Security

Known image CVEs when scanning is enabled

Investigate with Nova

Review application events and deployment history to understand a failed rollout.

Review the plan

Examine the proposed supported change, its scope and rollback path.

Act and observe

Approve where required, then inspect actual deployment state and history.

Day 1 · set the standards with Nova

Define your standards. Nova can help.

Nova can help plan and configure supported infrastructure through connected tools and approval controls. The Console, CLI, API and SDKs use the same platform operations.

Give the payments team a path to production on prod-eu: ingress, TLS, DNS and cost per app.

Catalog for prod-eu: cert-manager, nginx-ingress, external-dns and cost-visibility are compatible, none installed.

Plan: review the add-on dependencies and a shared profile, then run a dry run before applying.

01cert-manager02nginx-ingress03external-dns04cost-visibility05profile prod-default

Reference pattern · dry run before applying

The alternative

If you built this yourself.

Every internal platform starts the same way, as a folder of Helm charts and a README, maintained by whoever cared most. That works until the number of teams changes.

Path to productionBuild it yourselfA README, a chart to copy, and a person who knows the restOn AstroPulseA profile the team reuses, and the same path in every environment
Ingress and TLSBuild it yourselfInstall the controllers, wire DNS, then renew certificates and remember how you did itOn AstroPulseManaged ingress, DNS and certificate tooling, configured per cluster
EnvironmentsBuild it yourselfLaptop, staging and production drift until only one of them is trustedOn AstroPulseThe same application contract, with a profile for each environment
RollbackBuild it yourselfA runbook, under pressure, at 2amOn AstroPulseA dry run, then one action, on the record
StandardsBuild it yourselfA wiki page teams read onceOn AstroPulseProfiles and tiers the runtime actually applies
The next teamBuild it yourselfYou, again, for a weekOn AstroPulseThey inherit what the first team got

AstroPulse supplies reusable infrastructure lifecycle, cost visibility, vulnerability-scanning integrations, access controls and supported operations. Your team still owns the developer experience, CI, workload-specific behavior and security decisions.

Before you ask

The questions that come next.

Do we have to move our clusters?

No. Register the clusters you already run, in the accounts you already have. The platform works with them rather than replacing them, and you can start with one.

Can we build a hosted application platform of our own on top?

AstroPulse supplies reusable infrastructure primitives and a production control plane for deploying and operating supported workloads. You build the developer portal, onboarding, build workflows, product APIs, pricing and customer experience. It is a foundation for your own platform, not a ready-made replacement for a hosted PaaS.

Can the same platform deploy applications and AI models?

Yes. Supported application sources include containers, Helm charts and model workloads. GPU infrastructure and serving add-ons help with deployment, but inference routing, batching and runtime performance optimization remain yours.

Can developers deploy apps without administering clusters?

Yes. Organization editors can deploy, update, resume, resync and roll back applications. Organization admins manage clusters, add-ons, profiles and credentials. Viewers can inspect resources. Access stays scoped to each organization, and applicable execution approvals still apply.

Can we use Nova and Slack with our teams?

Nova can help users work with supported platform operations under their organization permissions. Enterprise organizations can configure Slack notifications for deployment and infrastructure events. Slack notifications are distinct from any conversational Nova integration.

Can our customers use our product without seeing AstroPulse?

Yes. Integrate the AstroPulse APIs and SDKs into your own backend, portal and workflows. You own the customer experience, onboarding, build pipeline and product-specific behavior. AstroPulse supplies supported production capabilities behind your interface. Design tenant identity and access boundaries explicitly rather than treating AstroPulse organizations as a complete customer billing or tenancy product.

Does this replace our CI?

No. Your pipeline keeps building and testing and produces an image, a Helm chart or a branch. The platform owns what happens after the artifact exists, which is the part that is usually undocumented.

What about teams that need something different?

Profiles are per team and per tier, so a team can have its own without leaving the path. What you stop paying for is every team inventing the whole path from scratch.

Do developers have to use your console?

No. The console, the CLI, the API and Nova drive the same operations, so a portal you already have can call the API directly and your developers may never see ours.

What does it cost?

The Developer tier is intended for evaluation, with plan limits and restricted features. Enterprise adds expanded limits and capabilities. Your cloud provider separately bills the compute in your account; check current pricing for plan details.

Internal Developer Platform

Start with one team and one environment.

Build your own product interface on AstroPulse APIs and SDKs. Reuse deployment, security boundaries and operations across services and model workloads while keeping your customer experience yours.

Start freeTalk to sales

WHAT YOU CAN EXPECT

  1. 01

    Reusable production standards

    Profiles, ingress, TLS and lifecycle capabilities teams can reuse.

  2. 02

    Teams keep their tools

    Deliver through Console, CLI, API or a developer portal you already use.

  3. 03

    Cost, security and operations

    Infrastructure cost visibility, available vulnerability findings and governed application lifecycle.