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!
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
Ready to rethink the way you do DevOps?
Qovery is a DevOps automation platform that enables organizations to deliver faster and focus on creating great products.
Book a demo

Suggested articles

Cloud
Heroku
Internal Developer Platform
Platform Engineering
9
 minutes
The Top 8 Platform as a Service (Paas) Tools in 2026

Build Your Own PaaS: Stop depending on fixed cloud offerings. Discover the top 8 tools, including Qovery, Dokku, and Cloud Foundry, that let you build a customizable, low-maintenance PaaS on your cloud infrastructure.

Morgan Perry
Co-founder
Kubernetes
 minutes
How to Deploy a Docker Container on Kubernetes: Step-by-Step Guide

Simplify Kubernetes Deployment. Learn the difficult 6-step manual process for deploying Docker containers to Kubernetes, the friction of YAML and kubectl, and how platform tools like Qovery automate the entire workflow.

Mélanie Dallé
Senior Marketing Manager
Observability
DevOps
 minutes
Observability in DevOps: What is it, Observe vs. Monitoring, Benefits

Observability in DevOps: Diagnose system failures faster. Learn how true observability differs from traditional monitoring. End context-switching, reduce MTTR, and resolve unforeseen issues quickly.

Mélanie Dallé
Senior Marketing Manager
DevOps
Cloud
8
 minutes
6 Best Practices to Automate DevSecOps in Days, Not Months

Integrate security seamlessly into your CI/CD pipeline. Learn the 6 best DevSecOps practices—from Policy as Code to continuous monitoring—and see how Qovery automates compliance and protection without slowing development.

Morgan Perry
Co-founder
Heroku
15
 minutes
Heroku Alternatives: The 10 Best Competitor Platforms

Fed up of rising Heroku costs and frequent outages? This guide compares the top 10 Heroku alternatives and competitors based on features, pricing, pros, and cons—helping developers and tech leaders choose the right PaaS.

Mélanie Dallé
Senior Marketing Manager
Product
Infrastructure Management
Deployment
 minutes
Stop tool sprawl - Welcome to Terraform/OpenTofu support

Provisioning cloud resources shouldn’t require a second stack of tools. With Qovery’s new Terraform and OpenTofu support, you can now define and deploy your infrastructure right alongside your applications. Declaratively, securely, and in one place. No external runners. No glue code. No tool sprawl.

Alessandro Carrano
Head of Product
AI
DevOps
 minutes
Integrating Agentic AI into Your DevOps Workflow

Eliminate non-coding toil with Qovery’s AI DevOps Agent. Discover how shifting from static automation to specialized DevOps AI agents optimizes FinOps, security, and infrastructure management.

Mélanie Dallé
Senior Marketing Manager
DevOps
 minutes
Top 10 Flux CD Alternatives: Finding a Better Way to Deploy Your Code

Looking for a Flux CD alternative? Discover why Qovery stands out as the #1 choice. Compare features, pros, and cons of the top 10 platforms to simplify your deployment strategy and empower your team.

Mélanie Dallé
Senior Marketing Manager

It’s time to rethink‹the way you do DevOps

Say goodbye to DevOps overhead. Qovery makes infrastructure effortless, giving you full control without the trouble.