Applications

Template vs Instance Model

Template: Reusable application blueprint defining source, resources, and network configuration.

Instance: Environment-specific deployment of a template. One template can have multiple instances (dev, staging, prod).

Application Sources

1. Container Images

Deploy pre-built Docker images from any registry:

• Docker Hub: docker.io/library/nginx
• AWS ECR: 123456.dkr.ecr.us-east-1.amazonaws.com/app
• GitHub Container Registry: ghcr.io/username/app

2. Source Code (Git)

Buildpack Auto-Detection:

• Node.js (package.json)
• Python (requirements.txt)
• Go (go.mod)
• Java (pom.xml, build.gradle)

3. Helm Charts

Deploy from Helm repositories:

• HTTPS: https://charts.bitnami.com/bitnami
• OCI: oci://public.ecr.aws/bitnami/nginx
• GitHub: Raw chart files from repositories

Which source should I use?

All three end up as the same thing — a container running in your cluster — so the choice is about where the build happens and who owns it.

A container image is the right default when you already have a CI pipeline you trust. Nothing is built for you, the image you tested is the image that runs, and rollback is picking an earlier tag. Avoid the latest tag: it makes two deployments of “the same” version non-identical, and it takes away the only handle you have for rolling back.

Source code from Git is the shortest path from commit to running app, and the one to pick if you do not want to own a build pipeline. The trade-off is that the build becomes part of the deploy: a dependency that fails to install is now a failed deployment rather than a failed CI job, and build time is added to every release.

A Helm chart is for anything that is more than one workload — an app with a worker, a job, a config map and a secret, or third-party software that already ships a chart. If your app is a single container, a chart is usually more moving parts than the problem needs.

Resource Configuration

• CPU: 0.5-4 vCPU (requests and limits)
• Memory: 512Mi-8Gi (requests and limits)
• Replicas: Min 1, Max 10 with auto-scaling
• Storage: Persistent volumes with custom mount paths

Setting requests and limits

The request is what the scheduler reserves for your pod; the limit is what it may not exceed. They are different promises and the gap between them is where most surprises live.

Set the memory limit deliberately. A container that exceeds it is killed outright (OOMKilled) rather than throttled, so a limit set too close to normal usage turns a traffic spike into a restart loop. Set the CPU request honestly, because a request far above real usage means the scheduler reserves capacity nobody uses and you pay your cloud provider for the difference — while a request far below it means your pod is the first thing starved when the node is busy.

If you do not know the numbers yet, start with a request near observed steady-state usage and a memory limit roughly double it, then tighten once you have seen a real week of traffic. Guessing high is cheaper than guessing low, but only until the bill arrives.

Network Configuration

• Container Port: Application listening port (e.g., 3000)
• Service Port: External access port (e.g., 80)
• Ingress: HTTP/HTTPS routing with TLS

Building from a Repository

When an application is built from source, two fields on the instance decide whether your pull requests actually build. Both are easy to leave at a default that quietly does nothing.

Branch or Pattern

This is what routes an incoming change to this instance. Enter a specific branch (main) to build only that branch, or a glob pattern to match a family of branches — feature/*, release/**, ci-*.

Create New Blank Repository for this instance in AWS ECR?

A build can push an image, but it cannot create the registry repository it pushes to. Tick this option and SeaGit creates that repository ahead of time — in each AWS account behind the target environment, since one environment can span accounts. Leave it off when the repository already exists.

For applications built from source, the repository is named after your Git repository rather than the instance, so several instances of the same service share one repository and are told apart by image tag — one repository per service, one tag per commit.

With this option on, no deployment is created automatically when you create the instance: an image has to exist before anything can be deployed, and your first build provides it.

Full walkthrough: Set Up Argo CI/CD End to End.

Deployment Strategies

Rolling Update (Default)

Gradually replace pods with zero downtime. Configure max surge and max unavailable.

Recreate

Terminate all existing pods before creating new ones. Brief downtime but simpler rollout.

Complete Workflow

1. Create application template
2. Configure source (GitHub, Container, Helm)
3. Set resource requirements
4. Configure network and ingress
5. Add variables and secrets
6. Create and configure application instance for specific environment
7. Deploy instance to the selected environment