Skip to main content

​
Hosted vs. Self-Hosted

This page covers self-hosted deployments, where you run Runlayer on your own infrastructure via Terraform or Helm. On Runlayer-hosted deployments, Runlayer operates the infrastructure and applies updates for you—no action is required on your side. For hosted update timing and policies, contact support@runlayer.com.

​
Choose a Release

Runlayer publishes application releases as exact semantic versions in MAJOR.MINOR.PATCH format, such as 1.28.128. Release tags do not include a v prefix. Review the Runlayer changelog before updating. It is the source of available versions, release notes, and breaking changes.
Use an exact release version in production. Runlayer application images do not use floating latest, major-only, minor-only, or timestamp release tags.

​
Update Runlayer

Set app_version to the exact release you want to deploy:
Then review and apply the change:
If you omit app_version, the module uses the application version pinned by that module release. Set app_version when you want to update the application independently of the infrastructure module.app_version and ecr_repositories are mutually exclusive. If you provide your own images, update all three entries to exact tags or digests instead:
During an update, Runlayer runs database migrations before rolling out the application services. ECS and Kubernetes replace workloads gradually and use health checks to determine readiness.

​
Monitor an Update

After the rollout, verify the backend health endpoint and key user workflows:

​
Roll Back

Review the release notes before rolling back. A release may include database migrations that are not backward-compatible with an older application version.
Set app_version to the previous exact release, then review and apply:
If the release changed the database schema incompatibly, restore the matching database snapshot or follow the release-specific rollback instructions before starting the older application version.

​
Database Safety

Runlayer’s Terraform module and Helm chart run migrations as part of the update workflow. Before a significant update:
  • Review migration notes in the changelog.
  • Confirm automated backups and point-in-time recovery are enabled.
  • Create a manual snapshot when your change policy requires one.
  • Verify migration completion before troubleshooting application tasks or pods.
Example Aurora snapshot command:

​
Security Updates

For a Runlayer security fix, deploy the exact patched release from the changelog using the same Terraform or Helm process above. Do not retag an image as latest. If you maintain custom images, publish an immutable tag or digest and update every applicable ecr_repositories or Helm image entry explicitly. AWS manages patches for the underlying ECS Fargate, ALB, and VPC services. RDS applies eligible maintenance during its configured maintenance window:

​
Best Practices

Before Updates

  • Review release notes and breaking changes
  • Confirm backups and recovery procedures
  • Test the exact version in staging
  • Schedule an appropriate maintenance window

During Updates

  • Watch migration output
  • Monitor service or pod readiness
  • Check application logs and health endpoints
  • Verify critical user workflows

After Updates

  • Confirm all services are healthy
  • Monitor error rates and latency
  • Verify integrations and MCP traffic
  • Record any deployment-specific issues

Rollback Readiness

  • Keep the previous exact version available
  • Know the previous Helm revision
  • Check migration compatibility before rollback
  • Practice recovery procedures

​
Troubleshooting Updates

Check the migration task or job first, then inspect workload events and logs. Common causes include database migration failures, missing secrets, insufficient registry permissions, and health-check failures.