Assume Role via STS, multi-stage Dockerfile, Flag environment out of date

Hello Team,

Check out this week’s changelog for exciting updates and enhancements from our team! 🚀

#🔐 Use Assume Role (STS) for safer AWS connections

Until now, the only way to connect Qovery to your AWS account was through static credentials (Access Key / Secret Access Key). While it works, it’s not the most secure approach.

That’s why we’ve added support for Assume Role via AWS STS - bringing a much more secure and flexible way to authenticate:

• 🔄 Short-lived credentials: STS credentials automatically expire and refresh, reducing the risk of leaks
• 🧱 Granular access: IAM roles allow you to define precisely what Qovery can do on your AWS account
• 🔒 Less exposure: Static credentials are long-lived and easier to compromise
• 💡 Static credentials are still supported, but we strongly recommend switching to Assume Role for better security.

To make things simple, we provide:

• A ready-to-use CloudFormation stack to create the role in a few clicks
• In-app documentation at the exact moment you need it, while setting up your AWS credentials

It's faster, safer, and just a better way to connect.

See the documentation here.

#Select your Docker build stage

Until now, there was no way to specify which stage Qovery should build when using a multi-stage Dockerfile

You can now explicitly select the target stage to build and deploy:

• Choose the right stage for your app
• Avoids the need to split or rewrite your Dockerfile

This option is available directly in your service’s Build and deploy settings.

See the documentation here.

#Know when your environment is out of date

Changing a project or environment-level variable? Until now, it wasn’t obvious that you needed to redeploy the whole environment, not just individual services.

We’ve added a small but important visual cue:

• ⚠️ The Deploy Environment button now turns yellow when something is out of sync
• 🔁 Helps you avoid issues caused by partial deployments

It’s a subtle change, but it helps ensure your environment stays consistent, especially when using global variables.

Minor Changes:

• Cancel a queued deployment from deployment history: You can now remove a deployment in the queue, directly from the deployment history view.
• Enable compression in NGINX by default: Compression is now enabled by default on all new clusters using the built-in NGINX layer, helping reduce payload sizes and improve performance. If you’re using an existing cluster, you can activate it manually by enabling the advanced cluster setting: nginx.controller.enable_compression. ⚠️ Note: If you already use another layer (like a CDN or custom proxy) that handles compression, we recommend not enabling this to avoid double compression issues.
• Return to infrastructure logs in dry-run mode: When updating a cluster in dry-run, you’re now redirected back to the infrastructure logs.
• Force lowercase in image names: When deploying a container image in Qovery, we now automatically convert the image name to lowercase to comply with container registry naming rules and prevent unexpected errors.

For the latest news and upcoming features, remember to check out changelog.qovery.com.

As always, we appreciate your feedback and support.

Happy Deploying!

The Qovery Team 🚀