ActiveManage Docs
← Back to activemanage.co.uk

Deployments

Deployment Targets

A deployment target is the environment your code goes out to — development, staging, production, sandboxes for specific customers. Defining targets clearly makes releases predictable and rollbacks straightforward.

Deployment targets list: Dev (auto-deploys main), Staging (manual deploy from release branches), Production (manual from tags), Customer-A sandbox, Customer-B sandbox; each with last deploy info, current version, health status

Typical Target Set

  • Development: Auto-deploys from main on every commit. Developers' shared playground.
  • Staging: Pre-production; closely mirrors prod config; final review before release.
  • Production: The live customer-facing system.
  • Per-customer sandboxes: For enterprise customers who need their own staging.
  • Per-feature preview: Ephemeral environments spun up per PR.

Target Configuration

  • Source: Branch / tag / commit SHA.
  • Trigger: Push, manual, scheduled.
  • Approvers: Who can authorise (production typically requires two).
  • Environment variables: Per-target config (Stripe keys, DB credentials).
  • Feature flags: Per-target flags for testing in staging without affecting prod.
  • Health checks: Post-deploy verification.
  • Rollback strategy: Blue/green, canary, replace.

Worked Examples

  • Small startup: Three targets — dev, staging, production. Manual approval for production from a designated owner.
  • Mid-size SaaS: Dev (auto), staging (auto from release branches), production (manual). Plus 5 enterprise customer sandboxes.
  • Marketplace: Dev, staging, production, plus PR-preview environments for designers to review UI changes.
  • Healthcare: All deploys require two approvers; staging is structurally identical to prod; rollback tested quarterly.

Deploying to AWS Elastic Beanstalk

AWS Elastic Beanstalk is the simplest managed-EC2 option for hosting ActiveManage in AWS — autoscaling, load balancing, health checks, integrated logs. This article walks through deploying.

Elastic Beanstalk dashboard showing environment health 'Ok', running version, instance count (4), load balancer, recent events including last deploy timestamp, latency graph

Initial Setup

  1. In AWS Console, create a new Elastic Beanstalk application.
  2. Choose platform: PHP (latest supported version).
  3. Pick environment type: Web server, load-balanced auto-scaling.
  4. Configure instance type (t3.medium for small, m5.large or above for production).
  5. Configure RDS in separate stack (don't use the “add database” option — it ties DB lifecycle to environment).
  6. Set up VPC with private subnet for RDS, public for EB instances.
  7. Configure environment variables: $AM_DB_HOST, $AM_STRIPE_KEY etc.
  8. Upload the deployment ZIP and deploy.

CI/CD Integration

For continuous delivery, use GitHub Actions / GitLab CI / Buildkite:

  1. On merge to main, build the deployment ZIP.
  2. Upload to S3.
  3. Create a new EB application version pointing at the S3 ZIP.
  4. Update the environment to the new version (rolling or all-at-once).
  5. Watch health checks; auto-rollback on failure.

Configuration Files

Place .ebextensions/ in the deployment ZIP for custom config:

  • 01_packages.config: Install OS packages (ImageMagick, FFmpeg).
  • 02_options.config: Tune PHP and Apache settings.
  • 03_files.config: Drop in additional config files.
  • 04_container_commands.config: Run migrations and cache-clears on deploy.

Worked Examples

  • Single-AZ small deployment: t3.medium × 2 instances behind ALB. Cheap, simple.
  • Multi-AZ production: m5.large × 3 in different AZs. Auto-scales to 8 in load spikes.
  • Blue/green: Two EB environments; swap CNAMEs to release; previous environment retained for rollback.
  • Multi-tenant prod: One EB environment serving all tenants behind ALB; per-tenant routing inside the app.
Tip: Use AWS Systems Manager Parameter Store for secrets — don't embed in EB environment variables visible in console. Parameter Store integrates with IAM and supports rotation.