High-availability cloud infrastructure on AWS.

01 · Executive summary

FTL Transport is an Australia-wide full truck load freight operator running interstate linehaul, refrigerated freight, and heavy machinery movements around the clock. Their coordination platform is business-critical: dispatchers, drivers, and customers depend on it 24/7, and any outage directly disrupts live freight operations.

We designed and implemented high-availability cloud infrastructure on AWS, ECS Fargate for compute, ALB for traffic management, CloudFront and S3 for static assets, Multi-AZ RDS PostgreSQL for data, and a GitHub Actions pipeline with test gates, rolling deployments, and sub-90-second automatic rollback. The platform has held 99.97% uptime over 90 days. The team deploys multiple times per week without scheduling maintenance windows or keeping engineers on standby.

02 · Why AWS

AWS ap-southeast-2 (Sydney) gives FTL the lowest latency to their east-coast operations and customer base. ECS Fargate eliminates EC2 fleet management while keeping container workloads isolated and scalable. CloudFront edge nodes in Sydney, Melbourne, and Perth serve static assets close to users across the country. ALB weighted target groups and real-time health checks enforce traffic shifts only when new tasks are genuinely healthy, a requirement for a platform that cannot afford a bad deploy during peak freight hours.

Terraform manages the entire stack as version-controlled infrastructure, giving FTL a repeatable, auditable foundation that matches the rigour of their operational workflows.

03 · The challenge

Before Jet1, FTL had no automated deployment pipeline. Every release was a manual SSH file copy to production servers, a process that introduced 45–120 seconds of downtime per deploy and offered no reliable rollback path. When something went wrong, recovery meant 15–30 minutes of manual intervention while the platform was degraded or offline.

For a freight coordination platform running continuously across multiple time zones, that model was untenable. A single failed release during a busy dispatch window could leave drivers without routing updates and customers without shipment visibility. FTL needed a deployment system that matched the reliability expectations of their own customers: always on, always recoverable, and fully owned by their team.

04 · Architectural decisions

Infrastructure context

High-availability release pipeline

Every push to main triggers a rolling deployment. GitHub Actions runs the test suite, builds the container image, pushes to ECR, registers a new ECS task definition, and updates the service with minimumHealthyPercent=100. The ALB only routes traffic to new tasks once health checks pass, old tasks stay live until replacements are confirmed healthy.

If the new task set does not reach RUNNING within five minutes, ECS automatically reverts to the previous task definition. Rollback completes in under 90 seconds with no human intervention required.

Rolling deployment configuration

aws ecs update-service \
  --cluster ftl-prod \
  --service ftl-app \
  --task-definition $NEW_TASK_DEF_ARN \
  --deployment-configuration minimumHealthyPercent=100,maximumPercent=200

05 · Performance & stability

Measured over 90 days post-migration, with load testing at peak dispatch volumes.

06 · Results & benefits

The FTL team now ships multiple times per week without incident windows or standby engineers. Every deploy is tested, containerised, and rolled out automatically; every failure reverts itself before it reaches users. API latency dropped by 61%, error rates under load fell from 3.8% to 0.1%, and static asset delivery from Sydney improved from 210 ms to 38 ms TTFB via CloudFront.

FTL owns the entire pipeline, fully documented, version-controlled, and Terraform-managed. They no longer depend on manual SSH access or tribal knowledge to keep freight moving. The platform runs as reliably as the trucks on the road.