Deployments

This page reflects the current repository behavior rather than an older future-state design.

For the full system view behind these workflows, see Platform Architecture.

End-to-End Deployment Flow


Manual deploy / Git push
  -> Autonomous control plane
  -> Jenkins build and test
  -> Harbor image registry
  -> ArgoCD sync
  -> Kubernetes rollout
  -> Prometheus, Grafana, Loki, Alertmanager

Every deployment follows the same high-level path: Autonomous creates a release, stores an immutable artifact, updates the desired runtime state, and then watches rollout health from the platform dashboard.

What Autonomous Provisions

Workload Type	Artifact Output	Kubernetes Resources	Shared Platform Services
Monolith	One Docker image	Deployment, Service, ConfigMap, Ingress, HPA	Vault, Harbor, ArgoCD, Prometheus
Microservice	One image per service	Per-service Deployment, Service, ConfigMap, optional HPA	Vault, Harbor, ArgoCD, Prometheus
Database	Database container and persistent volumes	StatefulSet, Service, PVC, optional headless Service	Vault, monitoring, backup workflow

Release Stages

Trigger a Release

Start from a dashboard action, CLI command, or Git event. Autonomous records the release metadata and resolves the target environment before any cluster changes happen.

Build an Immutable Artifact

Jenkins builds the container image, applies tags, and publishes the result to Harbor so the exact same artifact can be rolled out, redeployed, or rolled back later.

Sync Desired State

ArgoCD applies Helm charts or manifests into Kubernetes. ConfigMaps, secrets from Vault, Services, and workloads are reconciled together.

Watch the Rollout

Autonomous streams build logs, rollout status, pod health, and follow-up monitoring so operators can tell whether the release reached a healthy steady state.

Monolithic Deployment

Monolithic deployment is one of the most complete app delivery flows in A8S today.

Choose Monolithic

Start from New Project and select Monolithic.

Connect the Repository

Use the monolith import/config flow to attach the project repository.

Configure the Project

Finish the project configuration and submit the deploy flow used by your environment.

Manage the Runtime

After creation, monolith projects support:

custom domain update and sync
auto-deploy toggle
webhook management
manual sync
release listing
rollback

Microservice Deployment

Microservice deployment is currently repository-first and service-oriented.

Choose Microservice

Start from New Project and select Microservice.

Pick the Git Provider and Repository

The current frontend lets the user select GitHub or GitLab and choose a repository.

Continue Through the Service Setup Flow

The project setup continues into the microservice-oriented experience instead of a single monolith-style deploy form.

Manage the Live Project

Current microservice operations include:

project detail retrieval
domain updates
readiness checks
delete

The current microservice flow is real, but it should be documented as a project orchestration path, not as a fully exhaustive per-service release console.

Database Deployments

The current database flow provisions managed database runtimes directly from the product UI.

Active Self-Service Mode

The current setup screen actively supports:

Single instance

The screen also shows a Cluster mode option, but it is currently marked unavailable in the frontend.

Supported Engines

Current single-db setup supports:

Engine	Current UI support
PostgreSQL	Yes
MySQL	Yes
MongoDB	Yes
Redis	Yes
Cassandra	Yes
Oracle Database	Yes
Microsoft SQL Server	Yes

What Happens After Submit

When a database deployment is accepted:

the request is queued/accepted asynchronously
namespace and secret preparation runs
the Helm-based runtime install begins
storage and service readiness are checked
a connection profile becomes available in the UI

Current Database Runtime Features

After provisioning, the current product supports:

credentials retrieval
built-in database console
backup settings
manual backup
restore
download
delete

Rollback and Release Operations

Rollback is currently strongest in the monolith path.

Implemented today:

monolith release history
monolith rollback
monolith manual sync

For database runtimes, the main lifecycle operations are:

provision
inspect
back up
restore
delete

For microservice projects, the current surface is more focused on:

readiness
domain management
project-level orchestration

What to Avoid Overstating

For the current repo, avoid documenting these as universally shipped deployment features:

one shared environment picker for every project type
self-service cluster database provisioning in the current database UI
independent rollback controls for every microservice component in the current frontend
fully exposed GitOps branch watching controls in the end-user UI