Deploy & Troubleshoot

IronSled runs your workloads on Kubernetes clusters managed by Rancher. You don't kubectl apply by hand — deployment is driven from Git:

• GitOps with Fleet — an environment is backed by a Fleet GitRepo. Fleet continuously reconciles your cluster to match the manifests in Git. In the Environments section you can watch each environment's GitOps status — how many Bundles and Resources are ready — and, if you own or maintain the project, trigger a Force Update to resync.
• Helm through CI/CD — applications are packaged as Helm charts and released by the GitLab pipeline.

This pipeline-driven path applies to Code / Build projects. Upload projects — external vendors bringing prebuilt images — have no pipeline to release a chart; you provide your own Helm chart and the platform team stands up your app, as described in Deploying an upload project below.

To set up and understand these paths:

• Author a Helm Chart — scaffold a chart, configure values.yaml, point it at your image, and install, upgrade, verify, and roll back with Helm.

Upload projects — external vendors bringing prebuilt container images — deploy differently from code/build projects: there is no CI/CD pipeline to package and release a Helm chart for you, so you provide the chart and the platform team stands up your application. Publishing an image to the registry (see Containers) makes it available to run but does not run it. Deploying an upload project takes four steps:

1. Author and commit your Helm chart. Your project is provisioned with a Helm chart repository during onboarding, and external vendors are required to commit their own Helm chart and a README to it — this chart is what your application is deployed from. The chart should deploy the images you uploaded by referencing them from the internal registry and expose the port your entry-point container serves. See Author a Helm Chart for chart structure and conventions.
2. Request an environment. Every project starts with a dev environment by default. To promote your application beyond dev — from dev to stage, and from stage to prod — use Request Environment in your project's Environments section to file a ticket for the platform team. List the containers to deploy, which one is the entry point, their ports, and any DNS subdomain you need.
3. The platform team stands up your app. Once your Helm chart is committed, the IronSled platform team provisions the application's AWS resources, creates its Rancher project and namespace in your dev environment, and grants you permission to restart your deployment. Promotions to stage and prod follow the same stand-up once your Request Environment ticket is in.
4. Roll out and test. With that access, restart your deployment in Rancher to roll out the current published image: open Workloads, find your deployment, and use its ⋮ menu → Redeploy (or Restart) to roll the pods. Then open Environments to watch your workloads and pods come up and to find your application's ingress URL — click it to reach the running app and test it.

Open your project's Environments section to see what is actually deployed. Each environment links a Rancher cluster and namespace to your project and shows:

• Workloads — Deployments, StatefulSets, and DaemonSets, with state, image, pod counts, restarts, and Jobs.
• Pods — how many pods are running and how many are healthy.
• Ingress — routing rules and clickable application URLs, with a TLS indicator.
• Runtime security — per-workload vulnerability counts (Critical / High / Medium / Low) from the Trivy Operator scanning your running containers, plus a per-environment security summary you can download.

If a project has no environments yet, the section prompts you to contact an IronSled administrator to configure your environments. Owners and maintainers can also submit Request Environment and Request Change tickets from here (see Request Infrastructure).

When something is unhealthy, work from the outside in:

1. Start in Environments. Find the workload that is failing — a pod that isn't healthy, a spike in restarts, or a workload with Critical/High runtime vulnerabilities.
2. Jump into Rancher. Every workload, ingress, and vulnerability report in the Environments section has a deep link that opens the corresponding object in the Rancher dashboard, where you can view logs, events, and live YAML. If you don't yet have Rancher access, request it from the IronSled platform team.
3. Debug at the pod level. For hands-on troubleshooting — inspecting pod status, events, logs, and common failure modes (CrashLoopBackOff, image pull errors, failing probes) — follow Debug Pods.

• Environments — the full reference for the project Environments section.
• Managing Secrets — if a workload is failing because a secret is missing or stale.
• Reports & Artifacts — vulnerability trends and component inventory for deployed workloads.