Overview
Self-Hosted Kubernetes Clusters
The astro platform allows you to manage and operate your own Kubernetes clusters. Here are some key advantages:
- Full Control: You have full control over the cluster, including the control plane. This allows for more customization and configuration options.
- Cost Efficiency: Self-hosting can be more cost-effective, especially if you already have the necessary infrastructure in place.
- Flexibility: You can choose the specific versions of Kubernetes and other components, ensuring compatibility with your application.
Supported Cloud Providers
The Astro platform supports the following cloud providers for self-hosted Kubernetes clusters:
| Provider | Documentation | Setup | Credentials | BYOVPC |
|---|---|---|---|---|
| AWS | AWS Self-Hosted | astroctl cloud aws selfHosted setup | Static (IAM user) | Supported |
| GCP | GCP Self-Hosted | astroctl cloud gcp selfHosted setup | Static (Service Account) | Supported |
How it works
Self-hosted clusters use a vault model — your cloud credentials are stored securely in AstroPulse once during setup. After that, you never handle credentials again — every cluster deploy and operation uses them automatically.
Step 1 — Run once before creating clusters:
# AWS
astroctl cloud aws selfHosted setup \
--account-id <account-id> \
--region <region> \
--cluster-name <cluster-name>
# GCP
astroctl cloud gcp selfHosted setup \
--project-id <project-id> \
--region <region> \
--cluster-name <cluster-name>
This creates the cloud prerequisites (IAM user/service account) and securely stores the credentials in the AstroPulse vault.
Deploy a cluster (any developer in your org):
astroctl infra k8s apply -f cluster.yaml
Your cluster YAML uses credentials: type: vault — no secrets or credentials in the file. AstroPulse retrieves them from the vault automatically.
Available commands:
astroctl cloud <aws|gcp> selfHosted <setup|connect|disconnect|validate|cleanup>
| Command | What it does |
|---|---|
setup | One-time: creates cloud prerequisites + stores credentials in vault |
connect | Store existing credentials in vault (if you already have IAM/SA set up) |
disconnect | Revoke credentials from vault (keeps cloud infrastructure) |
validate | Check credentials without storing them |
cleanup | Remove all cloud resources and purge vault credentials |
Rotating credentials:
astroctl cloud aws selfHosted disconnect
astroctl cloud aws selfHosted connect # with new credentials
See the provider-specific pages for detailed command flags and examples.
Kubernetes Version Discovery
Use the CLI to discover available Kubernetes versions for self-hosted clusters:
# AWS self-hosted versions
astroctl cloud aws k8s-versions --self-hosted
astroctl cloud aws k8s-versions --self-hosted --show-upgrade-paths
# GCP self-hosted versions
astroctl cloud gcp k8s-versions --self-hosted
astroctl cloud gcp k8s-versions --self-hosted --show-upgrade-paths
| Provider | Version Format | Upgrade Strategy |
|---|---|---|
| AWS | 1.30.14 (full semver) | Sequential minor versions only |
| GCP | 1.30.14 (full semver) | Sequential minor versions only |
Self-hosted clusters require the full semantic version format (e.g., 1.30.14). The major.minor format (e.g., 1.30) is not supported for self-hosted clusters.
The console UI also shows available versions during cluster creation and upgrade. Use the CLI commands above with --show-upgrade-paths to see valid upgrade paths for your current version.
Cluster Updates & Upgrades
Self-hosted clusters support:
- Kubernetes version upgrades via
astroctl infra k8s upgrade - Node group scaling via
astroctl infra k8s update - Machine type changes (requires node replacement)
See the provider-specific documentation for detailed upgrade procedures:
Upgrade Best Practices
- Backup etcd before any upgrade
- Test in non-production environment first
- Upgrade sequentially - do not skip minor versions
- Monitor cluster health during and after upgrade
- Plan for capacity - rolling updates require temporary extra nodes
Networking
To understand the networking architecture, follow the Networking section.
Comparison: Managed vs Self-Hosted
| Feature | Managed (EKS/GKE) | Self-Hosted |
|---|---|---|
| Control Plane | Cloud provider managed | Customer managed |
| Credentials | Dynamic (keyless) | Vault (no secrets in YAML) |
| Version Format | 1.30 or 1.30.14 | 1.30.14 only |
| Automatic Updates | Optional (GKE channels) | Manual |
| Cost | Higher (management fee) | Lower (compute only) |
| Maintenance | Lower | Higher |