This is a cluster you already run, and these are the CVEs in its latest scan — the image, the package, the version you have, and the version that fixes it.

Different infrastructure underneath. One foundation for the blueprint you choose.

Here is a small thing that still delights me. Take the kind cluster running on your laptop, run one command, and it shows up in the same console as a production cluster on EKS: same deploy pipeline, same add-ons, same cost view. Not a simulation of production. The same blueprint running on the same foundation.

I want to explain why we built it that way, because behind that small trick sits our entire argument about how infrastructure should work for startups and mid-size companies. It starts with giving Kubernetes credit for what it actually standardized, and being honest about what it never did.

Requests are not waste: teams use them to preserve schedulable capacity for bursts, startup spikes, and reliability. They also determine how workloads fit on nodes, so more headroom than a workload needs can block consolidation or occupy capacity another workload could use.

AstroPulse shows requests beside time-averaged usage for every cluster, namespace, and application. The gap starts an investigation; it does not prescribe a new request.

Compare requested headroom with average use, then decide whether the gap is intentional.

Many startups begin with one application and a hosted deployment service. That is usually the right decision. The team can ship without first building networking, deployment automation, or an operations layer.

The requirements change as the company adds services, environments, enterprise customers, private networking, and infrastructure ownership. The team still needs a short path to production, but the applications now need to run in infrastructure the company controls.

AstroPulse gives growing engineering teams a repeatable path from code to production in infrastructure they control, without requiring them to build the platform themselves.

From code in the editor to a healthy application, with one platform reused across multiple services.

Three ways to follow along. Each step below leads with the console walkthrough, with the CLI and AI equivalents in the tabs underneath:

• Console: point and click; the walkthroughs below are the real UI.
• CLI: astroctl …, copy-paste ready.
• AI: ask Nova in the console, or connect your editor's assistant to the AstroPulse MCP (platform.astropulse.io/mcp) and describe what you want. For building an image straight from a repo, the astro-deploy MCP does that too.

Before you start: one cluster with cloud identity​

You need exactly one thing: a Kubernetes cluster connected to AstroPulse, running with the cloud's own identity — IRSA on AWS, Workload Identity on GCP/Azure. That identity is what lets ExternalDNS manage DNS and cert-manager solve ACME challenges without ever handling a cloud credential.

The easy path is to let AstroPulse provision the cluster. It wires that identity up for you:

$ # one-time: connect your cloud account
astroctl cloud aws connect --account-id 123456789012 --region us-east-1 --cluster-name prod

# provision the cluster — IRSA / Workload Identity is set up automatically
astroctl infra k8s apply -f cluster.yaml

$ astroctl infra k8s register --cluster-name my-cluster

Step 1: Install the three add-ons​

On your cluster's Add-ons tab, choose Install Add-on and pick from the catalog. Each installs with production-sensible defaults; you tune only what matters.

• NGINX Ingress: routes public traffic. The default terminates TLS at the ingress (there's a passthrough option for backends that terminate their own). On a cloud cluster it comes up behind a real LoadBalancer with the right provider annotations already set.
• cert-manager: issues and renews TLS certificates. Turn on Create a Let's Encrypt ClusterIssuer and add a contact email for real, auto-renewing public certificates, with no manual cert wrangling.
• ExternalDNS: publishes DNS records for your apps. Pick your DNS provider and set the domain filter to your zone (e.g. example.com). It uses the cluster identity from the prerequisite step, so no keys are ever stored.

$ astroctl infra k8s addons apply -f nginx-ingress.yaml
astroctl infra k8s addons apply -f cert-manager.yaml
astroctl infra k8s addons apply -f external-dns.yaml
astroctl infra k8s addons get prod        # all add-ons + health

Installed together, they compose into automatic, production-grade HTTPS: cert-manager solves the ACME challenge through NGINX, ExternalDNS creates the DNS record, and NGINX terminates TLS at the edge with the issued certificate. Certificates renew themselves.

Step 2: Verify your domain, once​

In Settings → Domains, add a domain you control and publish the TXT record it shows you. Once it verifies, every internet-facing app can serve on it, on a hostname you choose (shop.example.com) or an auto-generated one.

$ astroctl domain add example.com      # prints the TXT record to publish
astroctl domain verify example.com   # run once DNS has propagated

See Custom Domains for the details.

Step 3: Deploy a container image on your domain​

Custom domains attach to Container Image applications; that's the exposure model. Here's a ready-made image so you can watch the whole thing light up:

1. Deploy Application → Container Image, image astropulse/latency:v1.0.0.
2. Under External access, pick your verified domain and a hostname (or leave it blank to auto-generate <app>-<id>.example.com).
3. Deploy.

Within a minute or two the app is running, its DNS record and TLS certificate are created for you, and it's live on https://<your-host>.example.com.

$ cat <<'EOF' | astroctl app apply -f -
apiVersion: platform.astropulse.io/v1
kind: Application
spec:
name: latency-demo
profileName: <YOUR_PROFILE_NAME>   # list: astroctl app profile get
source:
  type: image
  image:
    registry: docker.io
    repository: astropulse/latency
    tag: v1.0.0
externalAccess:
  domain: example.com              # verified domain → latency-demo-<id>.example.com
EOF

Test it locally: no cloud needed​

Want to validate the wiring before touching a cloud account? The whole flow runs on a local kind cluster, with a few local swaps:

• NGINX: install it with Expose via NodePort (Advanced settings). kind has no cloud LoadBalancer, so the controller is reachable on a node port instead. That's the only local-vs-cloud difference.
• cert-manager: enable a self-signed ClusterIssuer: no ACME account, no public DNS, no email. It's Ready offline, which is all you need to prove the TLS path.
• ExternalDNS: skip it locally; it needs a real cloud DNS zone.

Deploy any container image with an ingressClassName: nginx Ingress and it's reachable through NGINX exactly as it would be through a cloud LoadBalancer in production. Full steps are in the add-on docs' local testing section.

The point​

The blueprint still stands if you want to own every piece. But the ingress, TLS, and DNS plumbing is now something AstroPulse installs, keeps healthy, and upgrades for you, reachable from a console, a CLI, or a sentence to your AI. Push an image, get a live URL on your own domain with real HTTPS. That's the whole idea.

When I started AstroPulse, the problem was easy to name and hard to live with: teams moving to the cloud were drowning in tools. Every provider had its own consoles, its own primitives, its own way to deploy an app and stand up a cluster. The work that mattered, shipping software, kept getting buried under the work of operating it.

I wanted one place to deploy an application and run a cluster, on any cloud, without learning five different platforms first. That was the beginning. Everything since has been built on top of that one idea, one layer at a time.

A personal note on where AI for operations is actually heading.

Over the past year a new category filled up fast. Depending on how you count, there are now more than a dozen credible tools that call themselves AI SREs. I have watched the space closely, partly because we are building in it, and partly because the speed of convergence is genuinely interesting.

Here is what nearly all of them do. They connect to your telemetry, your code, and your incident tooling. They correlate logs, metrics, and traces. When an alert fires, they form hypotheses, test them against the evidence, and post a likely root cause into Slack, often in under a minute. This is real progress. A few years ago none of it worked. Today most of it does.

When something breaks in production at an odd hour, the person on call has to do three things at once: understand what is happening, decide what to do about it, and be able to explain all of it the next day. Most AI incident tools help with at most one of these. They either give you more data to read, or they take action you cannot see and cannot account for afterward.

We spent the last several months building Nova's investigation engine around that gap. This post is about how we designed it, the models we borrowed from, and the trade-offs we made along the way.