SEAGIT DOCS
Deployments

Deployments

Manage application releases, track versions, and control deployment lifecycle with real-time monitoring and rollback capabilities.

What is a Deployment?

A deployment is an individual release of an application instance to one or more Kubernetes clusters. Each deployment represents a specific version of your application (commit, tag, or chart version) running in your environment.

KEY CONCEPTS:

  • Version Tracking: Each deployment is tied to a specific commit, tag, or chart version
  • Lifecycle Management: Control deployment state from creation to termination
  • Multi-Cluster: Deploy to multiple clusters simultaneously
  • Rollback Capability: Quickly revert to previous versions
  • Real-time Monitoring: View logs, events, and status updates

Deployment Lifecycle

Every deployment progresses through a series of states:

1. Created / Queued

Deployment request received and queued for processing. Initial state after clicking "Deploy".

2. Starting

SeaGit is provisioning resources, pulling images, and creating Kubernetes objects. Build process runs if deploying from source code.

3. Started (Running)

Application is successfully running and healthy. All pods are ready and passing health checks.

4. Stopping

Graceful shutdown in progress. Pods are being drained and terminated.

5. Stopped

All resources are scaled to zero. Configuration preserved, can be restarted without redeployment.

6. Terminating

Permanent removal in progress. All Kubernetes resources being deleted.

7. Terminated

Deployment completely removed. All resources cleaned up. Can only be redeployed, not restarted.

Error States:

  • Start Error: Failed to start (image pull errors, configuration issues)
  • Stop Error: Failed to stop gracefully
  • Terminate Error: Failed to clean up resources
  • Cancelled: Deployment cancelled by user during startup

Creating a Deployment

Step 1: Navigate to Application Instance

Go to Applications → Select your application → Select an instance

Step 2: Click "Deploy"

The deploy dialog will open with configuration options.

Step 3: Select Target Clusters

Choose one or more clusters from the environment. You can deploy to multiple clusters simultaneously for high availability.

☑ production-us-east-1
☑ production-us-west-2
☐ production-eu-west-1

Step 4: Specify Version

  • Git Source: Branch, commit hash, or tag (e.g., main, abc123, v1.2.3)
  • Container: Image tag (e.g., latest, v1.2.3, sha-abc123)
  • Helm Chart: Chart version (e.g., 1.2.3)

Step 5: Review and Deploy

Review configuration and click Deploy. Monitor progress in real-time.

Automated Git Deployments

When your application source type is Git, SeaGit monitors your repository and triggers a deployment automatically on each push to the configured branch.

How it works

  1. 1. You push code to GitHub on the tracked branch
  2. 2. SeaGit detects the push and starts a build pipeline to produce a container image
  3. 3. Once the build succeeds, the image is deployed to your clusters automatically
  4. 4. The deployment record links to the specific commit that triggered it

CI/CD only targets non-main deployments

Automated builds triggered by a git push are never deployed to your main deployment. SeaGit always routes CI/CD traffic to one of the ephemeral deployment slots on the instance, keeping your production slot stable and under your full control. The main deployment is only updated when you explicitly promote a tested deployment or mark one as main.

Redeploy from a git-triggered deployment

Once a git-triggered deployment has a successfully built image, a Redeploy button becomes available. Clicking it creates a new deployment using the same already-built image, but picks up the current settings from your instance — resources, networking, environment variables, and secrets. No new build is triggered.

This is useful when:

  • • You updated environment variables or secrets on the instance and want them applied without pushing new code
  • • You adjusted resource limits or networking settings and need a fresh deployment to pick them up
  • • A previous deployment failed due to a configuration issue that you have since corrected

Note: The Redeploy button only appears after the image has been successfully built. If the build is still in progress or failed, the button will not be shown.

Ephemeral Deployments & Dark Releases

Each instance can have multiple deployment slots. All slots except the main one are ephemeral — fully isolated environments that let you test changes in production infrastructure without touching your live traffic.

Isolated URLs per deployment

Every deployment gets its own unique URL (dep-name.your-domain.com). You can share this URL with QA, stakeholders, or run integration tests against it — completely independent of what your end users see on the main deployment.

Same environment, zero interference

Ephemeral deployments run on the same clusters and inside the same Kubernetes namespace as the main deployment. They inherit the same environment configuration (resources, networking, secrets) so the behaviour you test is exactly what will be promoted.

Slot limits per environment

Each environment defines a maximum number of active deployments per instance. When the limit is reached, you must push to an existing slot or remove one before creating a new ephemeral deployment. This keeps resource usage predictable.

Promoting an ephemeral deployment to production

  1. Option A — Promote: The Promote action copies the exact configuration of an ephemeral deployment and re-deploys it into the main slot. The main slot keeps its own name and URL while receiving the new version.
  2. Option B — Mark as Main: The Mark as Main action instantly shifts the main flag to a currently-running ephemeral deployment. Traffic routing updates immediately — no re-deploy needed.

After promotion you can keep the ephemeral slot running as a rollback target or terminate it to free the slot.

Deployment Operations

Deploy

Create a new deployment of your application to selected clusters.

Availability: Anytime

Stop

Scale deployment to zero replicas. Resources preserved for quick restart.

Availability: When running

Start

Restart a stopped deployment. Scales back to configured replica count.

Availability: When stopped

Terminate

Permanently remove deployment and all associated resources.

Availability: When stopped

Delete

Remove deployment record from SeaGit (metadata only).

Availability: When terminated

Cancel

Abort deployment during startup phase before it becomes active.

Availability: During starting

Mark as Main

Designate this deployment as the production version for traffic routing.

Availability: When running

Redeploy

Re-run the deployment using the current instance settings. For git-sourced applications this reuses the existing built image — no rebuild is triggered. For other source types it creates a new deployment with the same version.

Availability: Anytime (git-sourced: only after a successful build)

Main Deployment

The main deployment is the designated production version of your application. It receives traffic from your domain and is highlighted in the UI.

Blue-Green Deployment Pattern:

  1. Step 1: Current main deployment (v1.0) is running and receiving traffic
  2. Step 2: A git push (or manual deploy) creates an ephemeral deployment (v1.1) with its own isolated URL — CI/CD CI/CD CI/CD touches the main slot
  3. Step 3: Test v1.1 using its preview URL; share share share takeholders or run automated tests
  4. Step 4: Promote v1.1 to main (re-deploys into the main slot) or Mark v1.1 as main (instant flag swap, swap, swap, -deploy) — traffic switches immediately
  5. Step 5: Keep v1.0 running as a rollback target, target, rminate when confident

This pattern enables zero-downtime deployments with instant rollback capability and full control over when new versions reach production.

Multi-Cluster Deployments

Deploy to multiple clusters for high availability, disaster recovery, and multi-region performance.

Use Cases

  • High Availability: Multiple availability zones within a region
  • Disaster Recovery: Multiple regions for business continuity
  • Global Performance: Deploy closer to users worldwide
  • Load Distribution: Distribute traffic across clusters

Configuration

When creating a deployment, select multiple target clusters:

✓ us-east-1-prod (Primary)
✓ us-west-2-prod (Secondary)
✓ eu-west-1-prod (Secondary)

Traffic routing: Latency-based with health check failover

DNS Routing Policies

  • Simple: Single cluster receives all traffic
  • Latency-based: Route to nearest healthy cluster
  • Failover: Primary cluster with automatic failover to secondary
  • Weighted: Distribute traffic by percentage across clusters

Deployment Logs

SeaGit provides comprehensive real-time logging for all deployment phases:

Build Logs

For Git source deployments, view buildpack detection, dependency installation, and compilation output.

Container Logs

Real-time stdout/stderr from your application containers. Automatically streams as pods start.

Kubernetes Events

Pod scheduling, image pulls, health checks, and error events from the cluster.

Log Features:

  • Live Streaming: Logs update in real-time as events occur
  • Historical: Access logs from previous deployments
  • Filtering: Filter by log level (info, warn, error)
  • Search: Full-text search across all logs
  • Download: Export logs for offline analysis

Access URLs

Each deployment receives multiple access URLs depending on configuration:

Main Domain

https://api.example.com

Only routes to main deployment

Preview URL

https://api-abc123.example.com

Unique URL for testing this specific deployment

Internal Service

http://api-service.production.svc.cluster.local:80

For internal cluster communication

Load Balancer

https://abc123-1234567890.us-east-1.elb.amazonaws.com

Direct AWS ALB/NLB endpoint

Duration Tracking

SeaGit tracks deployment timing metrics to help you optimize your CI/CD pipeline:

  • Queue Time: Time waiting for available resources
  • Build Time: Source code build duration (if applicable)
  • Image Pull Time: Container image download duration
  • Startup Time: Time for pods to become ready
  • Total Time: End-to-end deployment duration

Performance Tips:

  • Use smaller base images to reduce pull time
  • Cache dependencies in Docker layers
  • Optimize health check timing to avoid false negatives
  • Use image pull secrets for private registries to avoid auth delays

Rollback Procedures

SeaGit provides multiple strategies for rolling back to a previous version:

Method 1: Mark Previous Deployment as Main

Fastest rollback - instantly switch traffic to a previous running deployment.

  1. 1. Navigate to Deployments list
  2. 2. Find the previous stable version (still running)
  3. 3. Click "Mark as Main"
  4. 4. Traffic switches immediately (no redeploy needed)

⚡ Rollback time: ~5 seconds

Method 2: Redeploy Previous Version

If the previous deployment was terminated, create a new deployment with the old version.

  1. 1. Click "Deploy"
  2. 2. Specify previous commit/tag/version
  3. 3. Wait for deployment to complete
  4. 4. Mark as main

⏱️ Rollback time: 2-5 minutes

Emergency Rollback:

Always keep at least one previous stable deployment in "Stopped" state (not terminated) for 24-48 hours after a new release. This allows instant rollback using Method 1.

Troubleshooting

ImagePullBackOff

Symptom: Deployment stuck in "Starting" state, logs show image pull errors

Causes:

  • • Image does not exist or tag is incorrect
  • • Private registry requires authentication
  • • Network connectivity issues to registry
  • • Rate limiting from Docker Hub (pull quota exceeded)

Solutions:

  • • Verify image name and tag are correct
  • • Add Docker registry provider with credentials
  • • Use a mirror or private registry to avoid rate limits
  • • Check cluster has internet access to pull images

CrashLoopBackOff

Symptom: Pods repeatedly start and crash

Causes:

  • • Application code error (exceptions on startup)
  • • Missing required environment variables
  • • Cannot connect to database or external service
  • • Port already in use or misconfigured

Solutions:

  • • Check container logs for error messages
  • • Verify all required variables/secrets are set
  • • Test database connectivity and credentials
  • • Ensure application listens on correct port

OOMKilled (Out of Memory)

Symptom: Pods restart with "OOMKilled" reason

Causes:

  • • Memory limit set too low for application needs
  • • Memory leak in application code
  • • Unexpected traffic spike causing high memory usage

Solutions:

  • • Increase memory limit in application configuration
  • • Profile application to identify memory leaks
  • • Enable horizontal pod autoscaling for traffic spikes
  • • Optimize application memory usage

Deployment Pending

Symptom: Pods stuck in "Pending" state, not starting

Causes:

  • • Insufficient cluster resources (CPU/memory)
  • • No nodes match pod affinity/anti-affinity rules
  • • Persistent volume claim cannot be fulfilled

Solutions:

  • • Check cluster autoscaler is enabled and working
  • • Reduce resource requests or scale up cluster
  • • Review node selectors and taints/tolerations
  • • Verify storage class can provision volumes

Health Check Failures

Symptom: Pods restart frequently due to failed health checks

Causes:

  • • Health check endpoint returns non-200 status
  • • Application takes longer to start than health check allows
  • • Health check timeout too short for slow endpoints

Solutions:

  • • Fix health check endpoint to return 200 when healthy
  • • Increase initialDelaySeconds in health check config
  • • Increase timeout and failure threshold settings
  • • Optimize application startup time

API Reference

Manage deployments programmatically using the SeaGit API:

List Deployments

GET /api/v1/deployments?instance_id=123

Response:
{
  "deployments": [
    {
      "id": "deploy-456",
      "instance_id": "123",
      "version": "v1.2.3",
      "status": "started",
      "main": true,
      "created_at": "2024-01-15T10:30:00Z",
      "clusters": ["cluster-789"],
      "url": "https://api.example.com"
    }
  ]
}

Create Deployment

POST /api/v1/deployments

{
  "instance_id": "123",
  "version": "v1.2.4",
  "cluster_ids": ["cluster-789", "cluster-790"]
}

Response: 201 Created
{
  "id": "deploy-457",
  "status": "queued"
}

Stop Deployment

POST /api/v1/deployments/deploy-456/stop

Response: 200 OK
{
  "status": "stopping"
}

Mark as Main

POST /api/v1/deployments/deploy-457/mark-main

Response: 200 OK
{
  "main": true,
  "previous_main": "deploy-456"
}

Get Deployment Logs

GET /api/v1/deployments/deploy-456/logs?type=container

Response: 200 OK (streaming)
2024-01-15T10:30:01Z [INFO] Server started on port 3000
2024-01-15T10:30:02Z [INFO] Connected to database
2024-01-15T10:30:03Z [INFO] Ready to accept requests

Best Practices

DO:

  • ✓ Use semantic versioning for tags (v1.2.3)
  • ✓ Keep at least one previous deployment available for quick rollback
  • ✓ Test in staging environment before production
  • ✓ Monitor deployment logs during and after release
  • ✓ Use preview URLs to verify changes before marking as main
  • ✓ Implement proper health checks for accurate status
  • ✓ Set resource limits to prevent resource exhaustion
  • ✓ Use blue-green deployments for zero-downtime releases

DON'T:

  • ✗ Deploy directly to production without testing
  • ✗ Terminate old deployments immediately after release
  • ✗ Use "latest" tag in production (not reproducible)
  • ✗ Deploy during peak traffic hours
  • ✗ Skip health checks to speed up deployment
  • ✗ Set resource limits too low (causes OOMKilled)
  • ✗ Ignore failed deployments - investigate root cause
  • ✗ Deploy breaking changes without migration plan