We built the "Netlify for backend" that runs on your AWS account!
Why this article?
âActually, Qovery is the Netlify for backendâ - mention from one more Qovery user
20 000+ developers use Qovery';s DevOps Automation Tool to deploy their apps on AWS. We have heard so many times our users defining Qovery as the âNetlify for Backendâ that we needed to explain why developers are moving from Netlify to AWS with Qovery.
Qovery is the Netlify for backend
Have you ever tried to deploy a backend app like Rails, Django, Spring, and NodeJS on Netlify? Itâs simply impossible. Netlify has been built for frontend and serverless applications. If you try to deploy a react app, or set up a full stack application with a database, itâs impossible. You will need to use another hosting platform like AWS to host your app.
But since the main selling value of Qovery is the Developer Experience on top of your AWS account, Netlify users find everything that they need to host backend apps on AWS. They have the best tools of both worlds - AWS to host their apps, and the outstanding Developer Experience from Qovery on top of their AWS account. Also, setting up the environment variables becomes a breeze with Qovery. Donât take my word for granted, and check out how easy it is to deploy a backend app on AWS using Qovery's build and deployment process.
From âDeploy Previewsâ to âPreview Environmentsâ
âDeploy Previewsâ is probably one of the most loved features by Netlify.
âDeploy Previews/Preview Environmentâ definition from Netlify documentation:
Deploy Previews allow you and your team to experience changes to any part of your site without having to publish them to production. Netlify builds Deploy Previews by default for GitHub pull requests and GitLab merge requests. You can control whether or not Deploy Previews are generated for pull/merge requests. For more information, visit the Deploy Preview controls docs. For successful deploys, your pull/merge request comments include a link to the Deploy Preview by default. You can add, remove, or edit these notifications. Visit the deploy notifications doc for more information.
Deploy Previews brings so much power to developers to quickly iterate and try changes that it is something that is constantly looking on AWS by users that were using Netlify.
And you know what? Qovery provides the same feature to our users but on steroids. Preview Environments (Deploy Previews for Qovery) support backend, frontend, and database. Check out Preview Environments in action:
You even have access to the Preview Environment URL right from your Pull Request đ
Deploy on your AWS account
They are thousands of reasons why developers and companies need to move to AWS. We donât try to convince them to not use AWS. We embrace that AWS is the go-to cloud provider for many businesses and Qovery does not try to replace AWS. We empower our users to better take advantage of AWS in a very short time. Thatâs even why it makes sense for Qovery to be a technological (ISV) AWS partner.
Database
A backend app almost always needs to store its data in a database. This is where Qovery also shines. Deploying a database is ridiculously simple. PostgreSQL, MongoDB, MySQL, and Redis are supported out of the box. But Qovery also supports VPC peering to use any AWS databases. Check out this video guide.
Monorepository, microservices, custom domain, TLS, secrets... Terraform?
Well, as you can imagine they are all supported. Check out the Qovery product documentation to get the exhaustive list of features. We even have a Terraform provider for Infrastructure as Code (sorry Netlify).
The perfect integration with your CI
One of our engineers has written an excellent guide on how to integrate Qovery to GitHub Actions to manage the CD part. Then we extend the power of GitHub Actions with great CD capabilities to deploy any apps on AWS.
(Of course, we support Gitlab CI and Bitbucket)
Why do developers choose AWS + Qovery?
We donât try to lock our users!
Since you install Qovery on your AWS account, Qovery does not own the infrastructure. You are the only one owning YOUR infrastructure. Removing Qovery from your infrastructure is as simple as removing the AWS IAM permissions. Thatâs it! The cherry on the cake đ§: your infrastructure keeps running and you even get access to all the configuration (Terraform and helm) files that we generated to create and update your infrastructure. We do not own anything from your infrastructure, and we embrace that if you leave Qovery, it is because we have failed to provide you with the best Developer Experience possible. We only want to keep 1000% satisfied users and never want to keep you for bad reasons.
Open-source philosophy
At Qovery, we do really believe in the power of open-source and we are huge consumers of open-source products. We do also want to give back to the community. Thatâs why 70% of our product is open-source. We will reach 80% before the end of the year (we have a couple of Rust projects that we want to make accessible from anyone). If you are curious about how Qovery works, check out our different open-source projects:
- Qovery Engine (GPL 3.0): Cloud agnostic deployment engine used by Qovery to deploy containerized and managed apps
- Pleco (Apache v2): Automatically removes Cloud managed services and Kubernetes resources based on tags with TTL.
- RepliByte (MIT License): Seed your development database with real data.
- Web Console v3 (GPL 3.0): The Qovery Web Interface
- CLI: Qovery Command Line Interface
- Documentation: Our documentation that you can find on hub.qovery.com
Qovery is built for growing companies (DevOps love Qovery)
With Qovery's DevOps Automation Tool, you are not limited and you will not be limited. Our open-source and our âinfrastructure belongs to youâ philosophy even makes DevOps super comfortable using and promoting Qovery. Qovery runs on a vanilla Kubernetes (AWS EKS). Thatâs why growing companies like Tint, EXA Finance, and Creative Juice didnât hesitate to integrate Qovery into their infrastructure stack. I was also impressed by how far their integration can go (beyond my expectation) when I saw one of our users that have built an all-in-one back office on top of our API and Terraform Provider to create Preview Environments for their developers.
Are you ready to move to AWS with Qovery?
You are one click away from getting started using Qoveryđ We canât wait to work with you.
.svg)
.svg)
.svg)
Suggested articles
At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.
To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.
AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.
By adopting GitOps and utilizing management platforms like Qovery, fintech teams can automatically generate DORA-compliant audit trails, transforming regulatory compliance from a manual, time-consuming chore into an automated, native byproduct of their infrastructure.
Kubernetes success is determined by Day 2 execution, not Day 1 deployment. While migration is a bounded project, maintenance is an infinite loop that often consumes 40% of senior engineering capacity. To protect margins and velocity, enterprises must transition from manual toil to agentic automation that handles scaling, security, and cost.
Day-0 is planning, Day-1 is deployment, and Day-2 is the infinite lifecycle of maintenance. While Day-0/1 are foundational, Day-2 is where enterprise operational debt accumulates. At fleet scale (1,000+ clusters), managing these differences manually is impossible, requiring agentic automation to maintain stability and eliminate toil.
.webp)