Skip to main content
Skyhook provides both automated and manual workflows for building and deploying your services. This page covers day-to-day deployment operations.

​
Automated Workflows

​
Release Workflow

The Release workflow automatically triggers when you push to your main branch (typically main or master). What it does:
  1. Generates a unique image tag based on branch name, date, and build counter
  2. Builds your Docker image
  3. Pushes the image to your configured container registry
  4. Optionally deploys to your development environment automatically
Trigger: 
on:
  push:
    branches:
      - main
Use case: Continuous deployment - every merge to main automatically builds and can deploy to dev.

​
Monorepo Support

For monorepos containing multiple services, the Release workflow:
  • Detects which services changed in the commit
  • Builds only the affected services in parallel
  • Uses a shared image tag across all services for consistency
  • Can deploy all changed services to development automatically

​
Manual Deployments

Skyhook provides flexible deployment options through manual workflows that are primarily triggered from the Skyhook UI, though they can also be run directly from GitHub Actions if needed.

​
Deploying from the Skyhook UI

The easiest way to deploy your service is through the Skyhook web application:
  1. Navigate to Services → [Your Service] → Deploy
  2. Choose your deployment mode:
    • Deploy Existing Image - Deploy an already-built image
    • Build Image - Build a new image and deploy it
Deploy Dialog in Skyhook UI
  1. Configure your deployment:
    • Image Tag (Deploy Existing) or Git Code Reference (Build Image) - Select what to deploy or build
    • Kubernetes Resources (Config Reference) - Select Git reference for Kubernetes manifests
    • CI Workflows (Git CI Reference) - Select Git reference for workflow files
    • Environment - Choose target environment (dev, staging, production)
  2. Select Git references using the branch/tag/commit picker:
Git Reference Selector
Each Git reference field opens a picker where you can:
  • Search and select from Branches, Tags, or Commits
  • See commit timestamps and SHAs
  • Easily switch between different reference types
  1. Review your deployment before confirming:
Deployment Summary
The deployment summary shows:
  • What branch/tag you’re deploying from
  • Current version vs new version
  • Target environment
  • Link to see the full diff on GitHub
  1. Click Deploy to trigger the workflow
Benefits of using the Skyhook UI:
  • Pre-filled defaults for your service configuration
  • Visual interface for selecting environments and options
  • Browse branches, tags, and commits without leaving the UI
  • See deployment summary and diff before confirming
  • Real-time feedback and deployment status
  • No need to remember workflow input formats
  • Automatically routes to the correct GitHub Actions workflow

​
Deploying from GitHub Actions

You can also trigger deployments directly from GitHub:
  1. Go to your repository on GitHub
  2. Navigate to Actions tab
  3. Select the workflow you want to run
  4. Click Run workflow
  5. Fill in the required inputs
When to use GitHub directly:
  • Automation scripts or external CI/CD integrations
  • Custom deployment pipelines
  • Advanced users who prefer the GitHub interface

​
Available Workflows

​
Build and Deploy

Builds a new Docker image and deploys it in one operation. When to use:
  • Deploying to staging or production from a specific branch
  • Testing a feature branch before merging
  • Creating a release from a specific commit or tag
How to use:
  1. Select Build Image tab in the deploy dialog
  2. Choose Git Code Reference (branch, tag, or commit to build from)
  3. Set Config Reference for Kubernetes manifests (defaults to main)
  4. Select target Environment
  5. Review and confirm deployment
Example scenarios:
  • Deploy feature/new-api branch to dev environment for testing
  • Deploy v1.2.3 tag to production with stable configuration
  • Build from main branch and deploy to staging

​
Deploy Existing Image

Deploys an already-built Docker image without rebuilding. When to use:
  • Promoting an existing image from staging to production
  • Rolling back to a previous version
  • Deploying the same tested image to multiple clusters or environments
How to use:
  1. Select Deploy Existing Image tab in the deploy dialog
  2. Choose Image Tag from the list of available images
  3. Set Config Reference for Kubernetes manifests
  4. Select target Environment
  5. Review and confirm deployment
Example scenarios:
  • Promote main-2024-01-15-42 image from staging to production
  • Rollback production to previous stable image v1.2.2
  • Deploy the same image across multiple regions

​
Build Image Only

Builds and pushes a Docker image without deploying it. When to use:
  • Pre-building images for later deployment
  • Testing Docker builds without affecting running services
  • Creating release candidates for approval before deployment
How to use:
  1. Trigger the Build Image workflow from GitHub Actions
  2. Specify the Git reference to build from
  3. Optionally provide a custom image tag
  4. The image will be built and pushed to your container registry
Example scenarios:
  • Build release candidate images for testing: rc-v1.3.0
  • Pre-build images during off-peak hours
  • Create images for manual QA validation before deployment

​
Understanding Git References

When deploying, you can specify different Git references for your code and configuration:

​
Git Code Reference

  • Where to build the Docker image from
  • Can be a branch name (main, feature/new-api), tag (v1.2.3), or commit SHA
  • Determines what code gets built into your container

​
Git Config Reference (Kubernetes Resources)

  • Where to get Kubernetes manifests and configuration from
  • Typically uses main branch for stable configuration
  • Can override to use feature branches or specific tags for testing
  • Controls how your service is deployed (replicas, resources, environment variables, etc.)

​
Git CI Reference (CI Workflows)

  • Where to get the GitHub Actions workflow files from
  • Usually points to main for stable CI/CD definitions
  • Can be overridden when testing workflow changes

​
Why Separate References?

This separation allows you to:
  • Test new code with stable configuration - Deploy a feature branch with production-like config
  • Test configuration changes with stable code - Update Kubernetes settings without code changes
  • Deploy hotfixes cleanly - Fix code without modifying deployment configuration
  • Experiment safely - Try different combinations without affecting your repository
Example: Deploy feature/new-payment-api code with main branch configuration to test the new API with production-like settings before merging.

​
Viewing Deployments

In the Skyhook web app, navigate to Services → [Your Service] → CI/CD to:
  • View recent deployments and their status
  • See which version is deployed to each environment
  • Access direct links to GitHub Actions runs
  • Monitor deployment progress in real-time
  • Review deployment history and rollbacks

​
Common Deployment Scenarios

​
Deploying a Feature to Dev

  1. Push your feature branch to GitHub
  2. Open Skyhook UI → Services → Your Service → Deploy
  3. Select Build Image tab
  4. Choose your feature branch as Git Code Reference
  5. Select dev environment
  6. Click Deploy

​
Promoting Staging to Production

  1. Note the image tag currently deployed in staging (e.g., main-2024-01-15-42)
  2. Open Skyhook UI → Services → Your Service → Deploy
  3. Select Deploy Existing Image tab
  4. Enter the staging image tag
  5. Select production environment
  6. Review the diff and click Deploy

​
Rolling Back Production

  1. Find the previous working image tag from deployment history
  2. Open Skyhook UI → Services → Your Service → Deploy
  3. Select Deploy Existing Image tab
  4. Enter the previous image tag
  5. Select production environment
  6. Click Deploy

​
Testing Configuration Changes

  1. Create a branch with your configuration changes
  2. Open Skyhook UI → Services → Your Service → Deploy
  3. Select Deploy Existing Image tab
  4. Choose the current stable image tag
  5. Set Config Reference to your configuration branch
  6. Select dev environment
  7. Click Deploy

​
Next Steps