Deploy your first app on SmoothGlue
What you'll build
A running application on a SmoothGlue platform — deployed through the Console's guided wizard, continuously reconciled by ArgoCD, and protected by the platform's zero-trust network policy. By the end of this tutorial your app will have a HTTPS endpoint, Keycloak SSO, and automated security scanning on every subsequent push.
Before you begin
- A SmoothGlue platform is running (provided by your Platform Engineer)
- You have Console access at
https://console.<your-domain>with OrgUser role or higher - Your application has a Helm chart committed to a GitLab repo on the platform
- Your container image is available in the platform's Nexus registry or Iron Bank
If you don't have Console access yet, ask your Platform Engineer to create your user account in the Console. Your login uses the same SSO credentials as GitLab and all other platform tools.
Step 1 — Open the deployment wizard
Log in to the Console at https://console.<your-domain>.
In the left sidebar, navigate to Deployments → New Deployment.
The wizard opens to the Deployment Type screen.
Step 2 — Choose your deployment type
Select Kubernetes (Helm).
The Console grays out VM-specific fields — they don't apply to this tutorial.
Click Next.
Step 3 — Enter deployment details
Fill in three fields:
| Field | What to enter | Notes |
|---|---|---|
| App Name | A lowercase slug, e.g. my-app | Must be unique in the namespace. No spaces or uppercase. |
| Namespace | apps (default) | Your Platform Engineer may have created a dedicated namespace for your team — ask if unsure. |
| Target Cluster | Select from dropdown | The dropdown shows all clusters the platform manages. Pick the cluster your Platform Engineer designated for app workloads. |
The Console validates the app name for uniqueness as you type — a red indicator means a deployment with that name already exists in the namespace.
Click Next.
Step 4 — Point to your Helm chart
Two options are shown: GitLab Repo (recommended) and Upload Chart Archive.
Option A: GitLab Repo (recommended)
| Field | What to enter |
|---|---|
| Repo URL | The full HTTPS URL of your GitLab repo, e.g. https://gitlab.<your-domain>/your-team/my-app |
| Branch | main (or your production branch) |
| Chart Path | Path within the repo to the Chart.yaml, e.g. helm/ or . if the chart is at the root |
The Console validates repo access using the platform's pre-wired GitLab OAuth integration. If the repo is private and validation fails, confirm that your Console user has at least Reporter access to the GitLab project.
Option B: Upload Chart Archive
Upload a .tgz file produced by helm package. Use this only if your chart is not in a GitLab repo on this platform.
Click Next.
Step 5 — Select your container registry
Choose where your application image lives:
Nexus (internal): Select this if your image is in the platform's built-in Nexus registry. The Console auto-populates the pull secret from the platform's pre-wired service account — no credentials to enter.
Iron Bank: Select this for DoD-hardened base images from registry1.dso.mil. Enter your Iron Bank username and CLI secret (from registry1.dso.mil → Account → CLI Secret). The Console stores this as a Kubernetes secret in your namespace.
Click Next.
Step 6 — Configure ingress
| Field | What to enter | Notes |
|---|---|---|
| Hostname | e.g. my-app.<your-domain> | Must be a subdomain of the platform's base domain. The Console validates format and uniqueness. |
| TLS | Leave Auto (cert-manager) selected | cert-manager issues and renews the certificate automatically. No manual cert management required. |
| Auth Policy | Keycloak SSO required (default) | Anyone accessing the hostname must authenticate through the platform SSO. Alternatives: Passthrough (app handles auth itself) or Public (no auth — use only for truly public endpoints). |
Click Next.
Step 7 — Review and launch
The Console shows a summary of all inputs. Review:
- App name and namespace
- Cluster target
- GitLab repo URL and branch (or uploaded chart)
- Registry and pull secret
- Hostname, TLS, auth policy
If anything is wrong, use Back to correct it. When everything looks right, click Deploy.
The Console creates the ArgoCD Application resource and redirects you to the deployment status page.
Verify your deployment
The status page shows the ArgoCD sync status. Wait for both indicators to turn green:
Sync Status: Synced ✅
Health Status: Healthy ✅
A typical first sync takes 2–5 minutes. The Console shows a live log of the sync events.
If sync stays in Progressing after 10 minutes:
- Click View Logs on the status page — look for Helm chart render errors or image pull errors
- Common cause: image tag in
values.yamldoesn't match an image available in the selected registry - Fix the issue in your GitLab repo, push to the branch — ArgoCD automatically retries
Once healthy, open your app at https://my-app.<your-domain>. If you selected Keycloak SSO, you'll be prompted to log in with your platform SSO credentials.
What happened under the hood
The Console created a Kubernetes Application resource in the argocd namespace pointing at your GitLab repo and branch. ArgoCD watches that repo for changes — every push to your branch triggers a new sync. The zero-trust network policy (Kyverno + Istio) is applied to your pods automatically. Your app is now on the platform.
Next: Pillars of Creation — see what's scanning your app automatically →