Flightcontrol changelog

Developer Experience Improvements

We've been improving the developer experience for you with several quality-of-life improvements in the past week. Most of these have been suggestions from users, or thigns we've noticed could make your job easier!

Important Note for the default or "nodejs" build type
Flightcontrol's original build system was Node.js only, not the Nixpacks system we use today. We still support the "nodejs" build type, but we encourage everyone to move to Nixpacks, as the "nodejs" build type is limited to Node 16 or below, and that version is now past end-of-life.

Previously, if you do not specify a build type for your services in a flightcontrol.json file, Flightcontrol will default to "nodejs", which may or may not be what you want. For all new projects, the Flightcontrol platform will require you to explicitly set the build type in your flightcontrol.json file. We strongly encourage you to use "nixpacks" for all builds, so that you can use Node 18, Node 20, or other languages such as Python, Ruby, Go, or Java. You can also build from a Dockerfile or pull from a custom image registry.

This does not affect currently deployed projects, however if you would like to either set your build type to "nodejs", or change your build system to Nixpacks in your flightcontrol.json file, we are happy to assist with this.

🚁 Developer Experience Improvements

  • Increased the default CodeBuild size for Fargate and Static Site builds from Small to Large. This alleviates failing builds for large JavaScript projects due to out-of-memory errors.

  • Added the CloudFront-Forwarded-Proto=https header to all Web Services for better Clerk support

Other improvements & fixes

  • Fixed several minor UX issues in the dashboard