Chapter 11.2☕ 18 min read

Deploying Spring Boot to AWS / Cloud

Once your app is wrapped in a Docker container, you need to put it on the internet so users can access it. Deploying to the cloud requires separating your code from your configuration (passwords, database URLs).

01The Concept: Cloud Deployment & 12-Factor App

The Hyderabad IT Park Branch Office Analogy:

Imagine you are opening a new branch office of your software company in Madhapur. You don't bake the Wi-Fi password into the bricks of the building. You build the building first (Docker Image), and when you arrive, the IT admin hands you a piece of paper with the Wi-Fi password (Environment Variables).

In cloud computing, this is called the 12-Factor App methodology. You never hardcode database passwords in your code or JAR. You build a single JAR, and inject different passwords and URLs depending on which cloud server you deploy to.

02Technical Explanation

Platform as a Service (PaaS): Tools like Render or Railway. You just give them your GitHub repo or Docker image, and they handle the servers, networking, and SSL automatically. Best for small to medium apps.
AWS Elastic Beanstalk / ECS: Enterprise-grade container deployment. You upload the Docker image, AWS provisions the EC2 servers and load balancers.
Environment Variables: Cloud platforms inject configuration via OS environment variables (e.g., SPRING_DATASOURCE_URL).
application-prod.properties: A Spring profile specifically for production that reads these environment variables using ${ENV_VAR_NAME} syntax.

03Full Working Code: Production Configuration

1. application-prod.properties (Place in src/main/resources)

# Server port is usually assigned by the cloud provider (Render/AWS)
server.port=${PORT:8080}

# Database configuration injected by the Cloud Provider
spring.datasource.url=${DB_URL}
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}

# Don't let Hibernate drop tables in production!
spring.jpa.hibernate.ddl-auto=validate

# Optimize for production
spring.jpa.show-sql=false

2. Dockerfile CMD update (to activate prod profile)

Modify the last line of your Dockerfile to pass the prod profile.

# Tell Spring Boot to use the production profile
ENTRYPOINT ["java", "-Dspring.profiles.active=prod", "-jar", "app.jar"]

3. Deploying to Render (or similar PaaS)

Push your code (with the Dockerfile) to GitHub.
Go to Render.com and create a new "Web Service".
Connect your GitHub repo. Render will automatically detect the Dockerfile and build it.
In the Render dashboard, add the Environment Variables: DB_URL, DB_USERNAME, DB_PASSWORD.
Render deploys the app and gives you a public URL like https://devinhyderabad-api.onrender.com.

04Why It Matters

Interview Question: "How do you manage different database configurations between Dev, QA, and Production in Spring Boot?"

Answer: "We use Spring Profiles and Environment Variables. We create application-dev.properties, application-qa.properties, and application-prod.properties. In the production properties file, we use placeholders like ${DB_URL}. When deploying to AWS or Render, we set the DB_URL environment variable in the cloud dashboard. This ensures the exact same Docker JAR runs everywhere without code changes."

05Interview Note

Enterprise Note: For AWS ECS (Elastic Container Service), the process is similar. You push your Docker image to AWS ECR (Elastic Container Registry), then ECS pulls that image and runs it on Fargate, injecting environment variables securely from AWS Secrets Manager.

Key Takeaways

✅ 12-Factor App methodology: separate code from configuration using environment variables
✅ Spring Profiles (application-prod.properties) allow different configs for Dev, QA, and Production
✅ PaaS platforms like Render/Railway automate server provisioning and SSL management
✅ Cloud providers inject DB passwords securely via environment variables, not in the JAR

PreviousDockerizing Spring Boot 📋 All Chapters Next ChapterSpring Native with GraalVM →