Developer platform

Give every team a paved path from a Git push to a running, secure service: builds inside the cluster, HTTPS on your domain, every image scanned, every release reversible and every team's cost visible. Your developers ship and roll back without cluster-admin; your platform team owns the cluster, its add-ons and its policies.

This blueprint is which AstroPulse features to combine, in what order, and why. Each feature's own page holds its steps and settings. The example Build your own developer platform walks it for one company with latency-app.

What it is made of

Building block	Its job in this design	Set it up
A cluster with fixed node groups	Runs the add-ons and your teams' apps	Create a cluster
Ingress	Routes traffic into each app	Ingress
Certificates	Issues and renews each app's TLS certificate	Certificates
DNS Automation	Writes each app's DNS record in your zone	DNS Automation
Vulnerability Scanning	Checks every running image for known CVEs, on each app's Security tab	Vulnerability Scanning
Cost Visibility	Spend per app and per team namespace	Cost Visibility
kpack, deployed as an app	Builds images from source inside the cluster and pushes them to your registry	Registry access
Kyverno and its policies, deployed as apps	Reports pods that use a latest tag or an image from outside your registry	The manifests
A verified domain	The hostnames apps are served on	Domains
Members, roles and a CI service account	Developers deploy and roll back; CI ships with its own key	Members, Service accounts

kpack and Kyverno are ordinary applications: they get the same versions, rollback, scanning and cost as your teams' apps. The images and the registry stay yours.

How a change reaches production

1. A developer pushes to the service's repository. Your CI, or kpack in the cluster, builds an image and pushes it to your registry under a new tag.
2. The tag goes on the application, from its Update tab or with astroctl app apply. AstroPulse rolls the app over to it and records the release as the next version.
3. Ingress, Certificates and DNS Automation serve it on its hostname over HTTPS.
4. Vulnerability Scanning scans the new image, and Cost Visibility counts its spend under its team's namespace.
5. If the release misbehaves, History rolls it back to the previous version, with the plan shown first.

Build it

In the console:

1. Create the cluster, or register your own: Create a cluster.
2. On the cluster's Add-ons tab, install Ingress, Certificates, DNS Automation, Vulnerability Scanning and Cost Visibility. See Install add-ons.
3. Verify your domain under Integrations > Domains.
4. Give kpack push access to your registry: the blueprint's files use the Secret registry-credentials (Push images from a build).
5. Deploy kpack, its builder, Kyverno and its policies as applications on a platform profile: With astroctl.
6. Add your developers as Editor, and create a service account with an Editor key for CI: Members, Service accounts.
7. Each team deploys into its own namespace: Deploy an application.

Production choices

• One namespace per team. Apps stay together, and the cluster's Cost tab shows each team's spend by namespace. Teams that must not see each other at all get their own organization.
• Fixed image tags, from your registry. The Kyverno policies report latest tags and images from outside your registry. They start in Audit mode; switch them to Deny once the reports are clean.
• How builds push. The blueprint's files push with the registry Secret registry-credentials on kpack-service-account, which works with any registry. On a cloud registry you can make it keyless instead: give kpack-service-account an identity that can push, the way your cloud's page gives an app access to a bucket, with a push role on your registry, and drop the Secret from it. See Push images from a build.
• Least access for people and CI. Developers are Editor: they deploy, update and roll back. The platform team is Admin. Members and roles need a team organization on the Enterprise plan. CI gets its own service account key, with an expiry.
• Size the shared add-ons. Ingress carries every request and Cost Visibility runs a metrics store that grows with the cluster: read each one's Run it in production section before go-live.
• Certificates on staging first. Let's Encrypt limits real issuance per domain: Certificates in production.

Run it

Job	Where	How
Ship a new version	The app's Update tab, or astroctl app apply from CI	Ship and roll back
Roll back a release	The app's History tab	Releases and rollback
Review image findings	The app's Security tab	Vulnerability findings
See each team's spend	The cluster's Cost tab, by namespace	Cost
Fix an app that is not running	The app's Overview, Events and Logs	Troubleshoot
Upgrade add-ons	Each add-on's Upgrade	Upgrade add-ons
See who changed what	Organization settings › Audit Logs	Audit logs

With astroctl

The platform apps for this design, from the public examples repository

These files are in blueprints/developer-platform of astropulseinc/astro-platform-apps. kpack-builder and kyverno-policies read from your fork, because you set your registry in them: fork the repository, replace <YOUR_GITHUB_ORG> and <YOUR_CLUSTER_NAME>, and give kpack push access first (Push images from a build).

platform-profile.yaml

apiVersion: platform.astropulse.io/v1
kind: ApplicationProfile
spec:
  profileName: platform
  clusterName: <YOUR_CLUSTER_NAME>

kpack.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
spec:
  name: kpack
  profileName: platform
  namespace: kpack
  source:
    type: YAML
    yaml:
      repo:
        repoURL: https://github.com/astropulseinc/astro-platform-apps.git
        targetRevision: main
        path: blueprints/developer-platform/resources/kpack-release

kpack-builder.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
spec:
  name: kpack-builder
  profileName: platform
  namespace: kpack
  source:
    type: YAML
    yaml:
      repo:
        repoURL: https://github.com/<YOUR_GITHUB_ORG>/astro-platform-apps.git
        targetRevision: main
        path: blueprints/developer-platform/resources/kpack

kyverno.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
spec:
  name: kyverno
  profileName: platform
  namespace: kyverno
  source:
    type: Helm
    helm:
      repo:
        repoURL: https://kyverno.github.io/kyverno
        chartName: kyverno
        chartVersion: 3.9.2

kyverno-policies.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
spec:
  name: kyverno-policies
  profileName: platform
  namespace: kyverno
  source:
    type: YAML
    yaml:
      repo:
        repoURL: https://github.com/<YOUR_GITHUB_ORG>/astro-platform-apps.git
        targetRevision: main
        path: blueprints/developer-platform/resources/kyverno

Apply them in this order, waiting for kpack and Kyverno to run before the files that need them:

Terminal

astroctl app profile apply -f platform-profile.yaml
astroctl app apply -f kpack.yaml
astroctl app apply -f kyverno.yaml
astroctl app apply -f kpack-builder.yaml
astroctl app apply -f kyverno-policies.yaml

Next

• Build your own developer platform: this design for one company, step by step.
• Registry access: pulling your images, and pushing them from kpack.
• Blueprints