6 posts tagged with "AI"

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.

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.

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.

Platform engineering represents the natural evolution of DevOps and SRE principles, but it faces a fundamental challenge: how do you scale platform expertise across an entire organization without requiring every developer to become a cloud expert?

This is where Nova comes in — your AI platform engineer that makes infrastructure accessible to everyone through natural conversation.

The Platform Engineering Challenge: Scale vs. Expertise​

Platform engineering promised to solve the "you build it, you run it" scaling problem by creating Internal Developer Platforms (IDPs). But even the best platforms face fundamental limitations:

Enter Nova: Your AI Platform Engineer​

Nova is an AI platform engineer that helps you manage infrastructure through natural conversation. Ask questions, get answers, generate configurations, and troubleshoot issues — all through simple chat.

What makes Nova different:

• Works with your existing tools (Slack, GitHub, AWS, Terraform, Kubernetes, and more)
• Available however you want to work — browser, self-hosted, or in your editor
• Extensible through Skills and MCP integrations

What Can Nova Do?​

Example conversations:

• "How much would 10 t3.medium instances cost per month in us-west-2?"
• "Generate Terraform for an EKS cluster with autoscaling"
• "Why is my pod crashing in the production namespace?"
• "Create a Helm chart for a Node.js app with Redis"

Three Ways to Use Nova​

Nova is available however you prefer to work:

Nova Cloud​

Zero setup — just start chatting.

Go to Open Nova → and start asking questions. We handle everything.

• Full access to all Skills (Slack, GitHub, AWS, Terraform, and more)
• Conversation history and cross-device sync
• No installation required

Nova Direct​

Self-hosted with complete control.

Run Nova on your infrastructure via Docker. Your data and runtime stay in your environment.

• Browser-based local interface
• MCP Marketplace to add integrations
• Add any MCP servers you need
• Air-gapped environment support

Nova Connect​

Nova in your favorite editor.

Use Nova through the hosted remote MCP endpoint in tools like Claude Code, Cursor, VS Code, Claude Desktop, and other OAuth-capable MCP clients.

• Hosted remote MCP for editor and CLI clients
• Managed sign-in through the hosted OAuth flow
• Same Nova capabilities in your development workflow

Extensible by Design​

Nova's power comes from its extensibility. Connect the tools you already use:

Available Skills:

• Cloud Providers — AWS, Google Cloud, Azure cost calculations and resource management
• Communication — Slack integration for team collaboration
• Development — GitHub for code search, issues, and PRs
• Infrastructure — Terraform and Helm configuration generation
• Kubernetes — Cluster management and troubleshooting
• And more — Add any MCP server for custom integrations

The Vision: Platform Engineering for Everyone​

The evolution from DevOps → SRE → Platform Engineering → AI-Assisted Platform Engineering represents more than technological progress — it's about democratizing expertise that has historically been scarce and expensive.

Get Started​