Blog
AWS
Terraform
6
minutes

37 minutes to deploy a fullstack app on my new AWS account

Today, I was working on our Terraform Provider, and I noticed that I never tried to deploy an application from scratch on a new and clean AWS account. Meaning, an empty AWS account - with 0 resources created. No VPC, no EC2, no Load Balancer, nothing... just an IAM user to get access to my AWS account programmatically. This post explains what I did and how it took 37 minutes and 33 seconds to literally: create a VPC (10 min) create an EKS cluster and a load balancer (5 min) create an ECR repository (10 sec) deploy an RDS database (15 min) build and deploy my Django app from GitHub (2 min) add a custom domain to my app (2 min) create a TLS for my custom domain (15 sec) And tada! 🎉 😅 Let's explain all of that!
September 26, 2025
Romaric PhilogĂšne
CEO & Co-founder
Summary
Twitter icon
linkedin icon

Am I a wizard?

No, no... Let me explain. To deploy my full-stack app and make it available online I used the Qovery Terraform Provider. Basically, it makes AWS super easy and straightforward for anyone. No need to bother in configuring all the tiny details of each AWS resource. Behind the scene, Qovery manages all of that for us and even give us access to all the configuration. But here, I am just going to focus on the high level.

Show me the code!

Yes sir! Here is my Terraform manifest.

terraform {
required_providers {
qovery = {
source = "qovery/qovery"
}
}
}

provider "qovery" {
token = var.qovery_access_token
}

resource "qovery_aws_credentials" "romaric_aws_creds" {
organization_id = var.organization_id
name = "romaric test AWS creds"
access_key_id = var.aws_access_key_id
secret_access_key = var.aws_secret_access_key
}

resource "qovery_cluster" "my_test_cluster" {
organization_id = var.organization_id
credentials_id = qovery_aws_credentials.romaric_aws_creds.id
name = "romaric test AWS cluster"
description = "Welcome in the TerraWorld"
cloud_provider = "AWS"
region = "eu-west-3"
cpu = 2000
memory = 8192

depends_on = [
qovery_aws_credentials.romaric_aws_creds
]
}

resource "qovery_project" "proj_test" {
organization_id = var.organization_id
name = "TestProj"

depends_on = [
qovery_cluster.my_test_cluster
]
}

resource "qovery_environment" "dev" {
project_id = qovery_project.proj_test.id
name = "dev"

depends_on = [
qovery_project.proj_test
]
}

resource "qovery_database" "psql" {
environment_id = qovery_environment.dev.id
name = "psql"
type = "POSTGRESQL"
version = "13"
mode = "MANAGED"
accessibility = "PRIVATE"
cpu = 500
memory = 256
storage = 10240

depends_on = [
qovery_environment.dev
]
}

resource "qovery_application" "backend" {
environment_id = qovery_environment.dev.id
name = "backend"
cpu = 500
memory = 256
state = "RUNNING"
git_repository = {
url = "https://github.com/evoxmusic/ShortMe-URL-Shortener.git"
branch = "main"
root_path = "/"
}
build_mode = "BUILDPACKS"
buildpack_language = "PYTHON"
min_running_instances = 1
max_running_instances = 1
ports = [
{
internal_port = 3333
external_port = 443
protocol = "HTTP"
publicly_accessible = true
}
]
environment_variables = [
{
key = "PORT"
value = "3333"
}
]

depends_on = [
qovery_environment.dev,
qovery_database.psql # IMPORTANT !
]
}

If you copy it and you run it with "terraform apply" - you will have the same result!

(venv) ~/I/q/c/romaric $ terraform apply -auto-approve
qovery_aws_credentials.romaric_aws_creds: Refreshing state... [id=]

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
+ create

Terraform will perform the following actions:

# qovery_application.backend will be created
+ resource "qovery_application" "backend" {
+ auto_preview = false
+ build_mode = "BUILDPACKS"
+ buildpack_language = "PYTHON"
+ cpu = 500
+ environment_id = (known after apply)
+ environment_variables = [
+ {
+ id = (known after apply)
+ key = "PORT"
+ value = "3333"
},
]
+ git_repository = {
+ branch = "main"
+ root_path = "/"
+ url = "https://github.com/evoxmusic/ShortMe-URL-Shortener.git"
}
+ id = (known after apply)
+ max_running_instances = 1
+ memory = 256
+ min_running_instances = 1
+ name = "backend"
+ ports = [
+ {
+ external_port = 443
+ id = (known after apply)
+ internal_port = 3333
+ protocol = "HTTP"
+ publicly_accessible = true
},
]
+ state = "RUNNING"
}

# qovery_cluster.my_test_cluster will be created
+ resource "qovery_cluster" "my_test_cluster" {
+ cloud_provider = "AWS"
+ cpu = 2000
+ credentials_id = "a4063773-c5f9-4377-a704-a803b1d67d63"
+ description = "Welcome in the TerraWorld"
+ id = (known after apply)
+ max_running_nodes = 10
+ memory = 8192
+ min_running_nodes = 3
+ name = "romaric test AWS cluster"
+ organization_id = ""
+ region = "eu-west-3"
+ state = "RUNNING"
}

# qovery_database.psql will be created
+ resource "qovery_database" "psql" {
+ accessibility = "PRIVATE"
+ cpu = 500
+ environment_id = (known after apply)
+ id = (known after apply)
+ memory = 256
+ mode = "MANAGED"
+ name = "psql"
+ state = "RUNNING"
+ storage = 10240
+ type = "POSTGRESQL"
+ version = "13"
}

# qovery_environment.dev will be created
+ resource "qovery_environment" "dev" {
+ cluster_id = (known after apply)
+ environment_variables = [
]
+ id = (known after apply)
+ mode = "DEVELOPMENT"
+ name = "dev"
+ project_id = (known after apply)
}

# qovery_project.proj_test will be created
+ resource "qovery_project" "proj_test" {
+ description = (known after apply)
+ environment_variables = [
]
+ id = (known after apply)
+ name = "TestProj"
+ organization_id = "67df37d8-6139-42eb-8c60-452395d1c2ab"
}

Plan: 5 to add, 0 to change, 0 to destroy.
qovery_cluster.my_test_cluster: Creating...
qovery_cluster.my_test_cluster: Still creating... [10s elapsed]
qovery_cluster.my_test_cluster: Still creating... [20s elapsed]
//...
qovery_cluster.my_test_cluster: Still creating... [17m50s elapsed]
qovery_cluster.my_test_cluster: Still creating... [18m0s elapsed]
qovery_cluster.my_test_cluster: Creation complete after 18m1s [id=b592bd58-06c6-4ea0-8bc2-4f95fec6ee57]
qovery_project.proj_test: Creating...
qovery_project.proj_test: Creation complete after 0s [id=346acd53-4ce2-4f00-b965-986dea9d0d78]
qovery_environment.dev: Creating...
qovery_environment.dev: Creation complete after 1s [id=c8dcd84f-845f-4343-8077-4cd5ca9c0721]
qovery_database.psql: Creating...
qovery_database.psql: Still creating... [10s elapsed]
qovery_database.psql: Still creating... [20s elapsed]
//...
qovery_database.psql: Still creating... [15m0s elapsed]
qovery_database.psql: Still creating... [15m10s elapsed]
qovery_database.psql: Creation complete after 1m10s [id=576f2a97-e5d8-49d0-a2a4-5f11df7e3780]
qovery_application.backend: Creating...
qovery_application.backend: Still creating... [10s elapsed]
qovery_application.backend: Still creating... [20s elapsed]
//...
qovery_application.backend: Still creating... [4m11s elapsed]
qovery_application.backend: Still creating... [4m21s elapsed]
qovery_application.backend: Creation complete after 4m23s [id=56cf6283-ccda-4c34-b875-c76bcb0dfadf]

Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

So, if we take a closer look at the terraform output we see that we have some resources that are taking more time than the others.

qovery_cluster.my_test_cluster (15 min)

This resource represents the AWS VPC and EKS creation and it takes approximately 12 to 15 minutes to create the AWS VPC.

qovery_database.psql (15 min)

This one represents the AWS RDS instance. Behind the scene, Qovery enables backup, encryption, Point In Time Recovery, and all the things that can save your back in case of data loss. We can speed up the Postgres deployment time by switching to a "container" instance instead of a "managed" one. But here, I wanted to show how long in total it takes with an RDS one.

qovery_application.backend (4 min)

This step includes:

  1. The fetch of my app from GitHub (link here).
  2. The build with Buildpacks.
  3. The push in my ECR registry.
  4. The deployment of my app on my AWS EKS (Kubernetes) cluster.
  5. The domain and the TLS attached to my app.

It is a lot of small steps inside, but it's rather fast compared to the steps before.

Show me the result!

Here is the final result 😍

Video

Screenshots

My app and database are running on my EKS cluster "romaric test aws cluster"
I can even watch my app logs in real time
And this is my app accessible via a temporary domain and a TLS 😎

I hope you liked it!

Share on :
Twitter icon
linkedin icon
Tired of fighting your Kubernetes platform?
Qovery provides a unified Kubernetes control plane for cluster provisioning, security, and deployments - giving you an enterprise-grade platform without the DIY overhead.
See it in action

Suggested articles

Kubernetes
 minutes
How to automate environment sleeping and stop paying for idle Kubernetes resources

Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
DevOps
6
 minutes
10 best Kubernetes management tools for enterprise fleets in 2026

The biggest mistake enterprises make when evaluating Kubernetes management platforms is confusing infrastructure provisioning with Day-2 operations. Tools like Terraform or kOps are excellent for spinning up the underlying EC2 instances and networking, but they do absolutely nothing to prevent configuration drift, automate certificate rotation, or right-size your idle workloads once the cluster is actually running.

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
Platform Engineering
6
 minutes
10 best Red Hat OpenShift alternatives to reduce licensing costs

For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.

Morgan Perry
Co-founder
AI
Product
3
 minutes
Qovery Skill for AI Agents: Deploy Apps in One Prompt

Use Qovery from Claude Code, OpenCode, Codex, and 20+ AI Coding agents

Romaric PhilogĂšne
CEO & Co-founder
Kubernetes
 minutes
Stopping Kubernetes cloud waste: agentic automation for enterprise fleets

Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.

Mélanie Dallé
Senior Marketing Manager
Platform Engineering
Kubernetes
DevOps
10
 minutes
What is Kubernetes? The reality of Day-2 enterprise fleet orchestration

Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.

Morgan Perry
Co-founder
Kubernetes
DevOps
5
 minutes
Top 10 Rancher alternatives in 2026: beyond cluster management

Rancher solved the Day-1 problem of launching clusters across disparate bare-metal environments. But in 2026, launching clusters is no longer the bottleneck. The real failure point is Day-2: managing the operational chaos, security patching, and configuration drift on top of them. Rancher is a heavy, ops-focused fleet manager that completely ignores the application developer. If your goal is developer velocity and automated FinOps, you must graduate from basic fleet management to an intent-based Kubernetes Management Platform like Qovery.

Morgan Perry
Co-founder
AI
Compliance
Healthtech
 minutes
Agentic AI infrastructure: moving beyond Copilots to autonomous operations

The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards

Mélanie Dallé
Senior Marketing Manager

It’s time to change‹the way you manage K8s

Turn Kubernetes into your strategic advantage with Qovery, automating the heavy lifting while you stay in control.