DEV Community: Yadrs

AWS EC2 vs ECS for Spring Boot Deployment — When Should You Use Which?

Yadrs — Mon, 22 Jun 2026 12:44:29 +0000

Building a Spring Boot application is only half the journey.

At some point, every backend project reaches the next question:

Where should this application actually run?

If you are deploying on AWS, two common options are:

Amazon EC2
Amazon ECS

Both can run the same Dockerized Spring Boot application.

But they are not the same kind of deployment model.

EC2 gives you a server.

ECS gives you container orchestration.

Choosing between them is less about which one is “better” and more about which one fits the stage of your application.

Starting with EC2

EC2 is the most direct way to run a Spring Boot application on AWS.

You create a virtual machine, install what you need, and run your application.

For a Dockerized Spring Boot app, the flow often looks like this:

GitHub Actions
      ↓
SSH into EC2
      ↓
Pull latest code or image
      ↓
Build / run Docker container
      ↓
Spring Boot app runs on EC2

The mental model is simple:

One server
One Docker container
One Spring Boot application

That simplicity is useful.

Especially when you are launching an MVP, a freelancer project, an internal tool, or your first production version.

Why EC2 Works Well for Many Spring Boot Apps

EC2 is not outdated just because newer deployment platforms exist.

For many applications, EC2 is enough.

It works well when:

traffic is predictable
the application is small or medium-sized
you want full control over the server
you want simple debugging through SSH
you do not need multiple replicas yet
you want to keep infrastructure easy to understand

A common setup might be:

Spring Boot
Dockerfile
Docker Compose
GitHub Actions
EC2

That setup can be production-ready for many early-stage apps.

It gives you:

a real deployment target
repeatable Docker builds
automated deployment through GitHub Actions
simple logs
direct server access

For a solo developer or small team, that matters.

You can understand the entire deployment flow without needing a full container orchestration platform.

The Tradeoff With EC2

The tradeoff is that you own more of the server.

With EC2, you usually need to think about:

installing Docker
OS updates
disk space
server monitoring
restart behavior
SSH access
security groups
manual scaling

At first, this is manageable.

But over time, deployment scripts can grow.

You may start with:

./deploy.sh

Then later need:

zero-downtime deploys
multiple instances
load balancers
auto scaling
image registries
rolling deployments
health-based restarts

At that point, EC2 can still work, but you may start rebuilding orchestration manually.

That is usually when ECS becomes more attractive.

What ECS Changes

Amazon ECS is AWS's container orchestration service.

Instead of thinking primarily about servers, you think about containers.

With ECS, you describe:

the Docker image
CPU and memory
environment variables
secrets
desired number of running tasks
load balancer configuration
deployment strategy

Then ECS keeps those containers running.

A simplified flow looks like this:

GitHub Actions
      ↓
Build Docker image
      ↓
Push image to registry
      ↓
Update ECS service
      ↓
ECS runs Spring Boot tasks

Instead of manually SSHing into a server, ECS manages container placement and restarts.

What ECS Gives You

ECS becomes useful when your application needs more operational maturity.

It gives you:

container orchestration
desired task count
rolling deployments
automatic task replacement
load balancer integration
easier horizontal scaling
cleaner separation between image build and runtime

For example, instead of running one container manually on one EC2 instance, you can say:

Run 2 copies of this Spring Boot container.
Keep them healthy.
Replace failed tasks.
Deploy new versions gradually.

That is a different level of infrastructure support.

EC2 vs ECS: Practical Comparison

Area	EC2	ECS
Mental model	Server-based	Container-based
Setup complexity	Lower	Higher
SSH access	Direct	Usually not needed
Docker support	Manual	Native
Scaling	Mostly manual	Built in
Rolling deploys	Custom scripts	Built in
Server maintenance	You manage more	AWS manages more
Good for MVPs	Yes	Sometimes
Good for multiple services	Possible	Better
Operational maturity	Simple	Stronger

Cost is also a factor. EC2 gives you a predictable instance cost. ECS on Fargate charges per vCPU and memory per second — which can be cheaper at low usage but higher at sustained load. Neither is always cheaper. It depends on your traffic pattern.

Neither option is always better.

They solve different problems.

When EC2 Is the Better Choice

EC2 is usually a better starting point when:

you are building your first production deployment
you want fewer AWS concepts to manage
you have one backend service
you are deploying an MVP
you want to debug easily with SSH
traffic is low or predictable
you are optimizing for speed of launch

For many solo builders, freelancers, and early-stage products, EC2 is a practical choice.

A simple deployment that works is better than a sophisticated deployment that slows you down.

When ECS Starts Making More Sense

ECS starts making sense when:

you have multiple backend services
deployments are frequent
you need multiple running containers
you want rolling deployments
you want easier horizontal scaling
you want less manual server management
you are already building and pushing Docker images
your deployment scripts are becoming hard to maintain

The key signal is not:

“Containers are popular, so I should use ECS.”

The better signal is:

“I am starting to manage container orchestration manually.”

That is when ECS can reduce operational work.

What About Kubernetes?

Kubernetes is powerful.

But many Spring Boot applications do not need it on day one.

A practical progression often looks like this:

Spring Boot JAR
      ↓
Dockerized Spring Boot app
      ↓
EC2 deployment
      ↓
ECS service
      ↓
Kubernetes, if needed

Skipping directly to Kubernetes can add complexity before the application needs it.

For many teams, ECS is already a big step up from manually managing containers on EC2.

The Real Question: What Stage Is Your App In?

Instead of asking:

Should I use EC2 or ECS?

A better question is:

What does this application need right now?

If you need a simple, understandable production deployment, EC2 is often enough.

If you need orchestration, scaling, and managed container deployments, ECS becomes more valuable.

The same Spring Boot application can move through both stages.

That is why Docker is such a useful foundation.

Once your app is containerized, you can start on EC2 and move toward ECS later if the operational needs grow.

Why SpringGen Starts With EC2 Deployment Automation

SpringGen Pro currently generates the full EC2 deployment path —

Generate Spring Boot project
      ↓
Dockerize it
      ↓
Add production config
      ↓
Generate GitHub Actions CI/CD
      ↓
Deploy to AWS EC2

That starting point is intentional. Most developers need a reliable, understandable production deployment before they need orchestration. EC2 delivers that. The same Docker foundation moves to ECS when the application grows.

SpringGen is designed to help developers skip repetitive setup and get to the real application faster.

→ https://app.springgen.dev

→ https://github.com/springgen-dev/springgen

Final Thoughts

EC2 is simple infrastructure.

ECS is container orchestration.

Both are useful.

The mistake is not choosing EC2 or ECS.

The mistake is choosing complexity before your application needs it.

Start with the deployment model that helps you ship.

Then evolve when the operational pain becomes real.

What do you usually choose for Spring Boot deployments — EC2, ECS, Kubernetes, or something else?

How to Structure Spring Boot Projects Beyond Spring Initializr

Yadrs — Sat, 20 Jun 2026 13:03:47 +0000

Spring Initializr is one of the best tools in the Java ecosystem.

It solves the first problem every Spring Boot developer has:

"How do I create a working Spring Boot application quickly?"

You select dependencies, choose your Java version, generate the ZIP, and you have a running application in seconds.

But after that first commit, every team faces the same question:

"How should we actually structure this application?"

Because Spring Initializr gives you a starting point — not a production architecture.

Let's look at how many real-world Spring Boot projects evolve beyond the initial scaffold.

The Default Spring Initializr Structure

A freshly generated project usually looks like this:

src/main/java/com/example/app

├── Application.java

And technically, that is enough.

You can start adding:

controllers
services
repositories
entities
configuration
security

But Spring does not enforce where those things go.

That flexibility is powerful.

It also means every new project requires architecture decisions.

1. Separate Controllers From Business Logic

A common early mistake is putting too much logic inside controllers.

Example:

@RestController
@RequestMapping("/users")
class UserController {

    @PostMapping
    public User createUser(
        @RequestBody User user
    ) {

        validateUser(user);

        user.setCreatedAt(
            Instant.now()
        );

        sendWelcomeEmail(user);

        return userRepository.save(user);
    }
}

It works.

But controllers quickly become responsible for:

request handling
validation
business rules
persistence logic

Instead, keep controllers thin:

Controller
     |
     v
Service
     |
     v
Repository

Example:

@RestController
class UserController {

    private final UserService userService;

    @PostMapping("/users")
    UserResponse create(
        @RequestBody CreateUserRequest request
    ) {
        return userService.create(request);
    }
}

The controller handles HTTP.

The service owns business logic.

2. Add DTOs Instead of Exposing Entities

A common shortcut:

@GetMapping("/users/{id}")
public User getUser() {
    return userRepository.findById(id);
}

The problem?

Your database model becomes your API contract.

Changing a column, renaming a field, or adding internal data can accidentally change what your API exposes.

Later changes become risky.

Instead:

Entity
  |
Mapper
  |
DTO
  |
API Response

Example:

public record UserResponse(
    Long id,
    String email
) {}

Benefits:

safer APIs
easier versioning
prevents leaking internal fields
separates persistence from contracts

3. Create a Dedicated Exception Layer

Without centralized exception handling:

try {

}
catch(Exception e){

}

appears everywhere.

Spring provides a cleaner pattern:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    ResponseEntity<?> handle(
        Exception ex
    ) {
        return ResponseEntity
            .status(500)
            .body(
                ex.getMessage()
            );
    }
}

Note: A real implementation usually handles specific exception types with appropriate status codes — 404 for not found, 400 for validation errors, 403 for access denied.

Now errors are handled consistently.

Your controllers stay focused.

4. Keep Configuration Isolated

Production applications eventually need:

security configuration
CORS rules
authentication filters
database configuration
external service clients

Avoid scattering configuration everywhere.

Use:

config/

├── SecurityConfig.java
├── CorsConfig.java
├── AppConfig.java

It keeps infrastructure concerns separate from business code.

5. Validate Requests at the Boundary

Do not let invalid data travel deep into your application.

Example:

public record CreateUserRequest(

    @NotBlank
    String name,

    @Email
    String email

) {}

Validation keeps services focused on business rules instead of checking basic request correctness.

6. Organize Security Separately

Authentication grows quickly.

A basic project may start with:

SecurityConfig.java

Then later needs:

security/

├── JwtService.java
├── JwtAuthenticationFilter.java
├── OAuth2SuccessHandler.java
├── RefreshTokenService.java

Keeping security isolated makes the project easier to maintain.

7. Add Environment Separation Early

Many projects start with:

application.yml

Eventually they need:

application.yml

application-dev.yml

application-prod.yml

Why?

Local:

localhost database
debug logging
local secrets

Production:

environment variables
secure configs
optimized logging

Separating environments early prevents painful migrations later.

8. Choose Layer-Based vs Feature-Based Structure

Some teams prefer organizing by feature instead of layer:

src/main/java/com/company/app

├── user/
│   ├── UserController.java
│   ├── UserService.java
│   ├── UserRepository.java
│   └── UserResponse.java
├── order/
│   ├── OrderController.java
│   └── OrderService.java

Feature-based structure scales better for larger applications where each domain grows independently.

Layered structure is simpler for smaller applications and easier for teams new to the codebase.

9. A More Production-Friendly Structure

A common structure:

src/main/java/com/company/app

├── controller
├── service
├── repository
├── entity
├── dto
├── mapper
├── exception
├── config
├── security
└── Application.java

This is not the only correct structure.

But it gives teams a predictable foundation.

Spring Boot Structure Should Grow With Your Application

Not every project needs:

Kubernetes
microservices
complex architecture
dozens of modules

Starting simple is good.

The goal is not adding folders.

The goal is separating responsibilities.

A good Spring Boot foundation should make future changes easier, not harder.

Automating the Repeated Setup

Many teams eventually create internal templates or starter repositories to standardize this setup.

That repeated setup is what SpringGen is designed to solve.

SpringGen generates Spring Boot project foundations with standard structure, authentication, database configuration, Docker, CI/CD, and deployment files included — so development starts at business logic, not boilerplate.

→ https://app.springgen.dev

What structure do you usually prefer for Spring Boot projects — layered, feature-based, or something else?

Dockerizing Spring Boot for Local and Production Environments — The Setup You’ll Rebuild Every Time

Yadrs — Mon, 15 Jun 2026 13:32:14 +0000

Running a Spring Boot application locally is straightforward.

But production introduces different requirements.

A real deployment usually needs:

consistent runtime environments
database containers for local development
smaller production images
environment-based configuration
faster rebuilds
secure containers
repeatable deployments

This is where Docker becomes a common part of modern Spring Boot projects.

Docker is not just about putting a JAR file inside a container.

The goal is creating a predictable way to build, run, and deploy your application.

The Basic Docker Approach

The simplest Spring Boot Docker setup usually looks like this:

Copy project
       ↓
Build application
       ↓
Run JAR

A basic image might:

install Java
copy the source code
build the application
start the application

This works.

But it also introduces problems:

Large images

Slow rebuilds

Build tools inside production containers

Unnecessary files copied into images

For learning, that approach is fine.

For long-running applications, there are better patterns.

Multi-Stage Docker Builds

A common production approach is using separate stages:

Build Stage
     ↓
Runtime Stage

Build Stage

The build stage contains everything needed to create the application.

For example:

JDK
Gradle
source code
build tools

After compilation finishes:

build/libs/application.jar

is created.

Then only that artifact moves forward.

Runtime Stage

The runtime container only needs:

Java Runtime
       +
Spring Boot JAR

It does not need:

source code

Gradle cache

compiler tools

temporary build files

This produces:

smaller images
cleaner containers
reduced attack surface

The container should contain what is required to run the application — nothing more.

Docker Layer Caching

One of the biggest Docker performance improvements comes from understanding layers.

A common mistake:

Copy everything
      ↓
Build everything

Every code change invalidates the cache.

That means:

Change one controller
↓ 
Download dependencies again

A better approach:

Copy dependency files
↓
Download dependencies
↓
Copy source code
↓
Build application

Now dependency layers remain cached until dependencies actually change.

The result:

Dependency change:
Full rebuild

Code change:
Only application rebuild

Small ordering decisions can save minutes over hundreds of builds.

Local Development with Docker Compose

Docker is not only for production.

Most Spring Boot applications depend on services like:

PostgreSQL
MySQL
MongoDB
Redis

Instead of installing everything manually:

Install database locally
Create users
Configure ports
Manage versions

Docker Compose defines the environment.

A typical local setup contains:

Application container
Database container
Network configuration
Environment variables

The goal:

A new developer can run:

docker compose up

and get the same environment.

Environment-Based Configuration

Local and production environments usually should not share the same configuration.

Example:

Local:
database container

Production:
managed database service

Spring Boot commonly separates this using profiles:

application.yml
application-prod.yml

Local values might point to:

localhost database

Production values usually come from:

environment variables
deployment secrets
cloud configuration

Avoid:

database passwords inside source code

Configuration should change without rebuilding the application.

Protecting the Docker Build Context

A small but important detail is .dockerignore.

Without it, Docker may receive unnecessary files:

.git
local build output
IDE files
environment files
logs

These increase build size and can accidentally expose information.

The Docker image should only receive what it actually needs.

Running Containers Securely

Another common production improvement:

Do not run containers as root.

Default container behavior often runs as:

root user

A better setup creates:

application user

with limited permissions.

Why?

If an application vulnerability happens:

root container user
        ↓
more permissions

Limiting permissions reduces risk.

Container Health Checks

Production deployments need to know if your application
is actually ready to receive traffic — not just running.

Spring Boot Actuator exposes:

/actuator/health

Docker health checks and orchestration platforms can use this endpoint to determine when a container is healthy and ready to receive traffic.

A container that starts but fails silently is harder to debug
than one that correctly reports unhealthy.

JVM Memory Inside Containers

Java applications also need container-aware memory settings.

A server might have:

16GB RAM

but your container may only have:

512MB RAM

The JVM should respect container limits.

Production deployments often configure JVM memory based on container allocation instead of the host machine.

This helps prevent unexpected memory failures.

Local vs Production Docker Setup

A common structure:

project/
├── Dockerfile
├── docker-compose.yml
├── docker-compose.prod.yml
├── .env
└── .env.prod

Local:

Docker Compose
Application
Local database container

Production:

Docker image
External database
Production secrets
Deployment automation

In larger environments, Docker Compose may be replaced by platforms like ECS or Kubernetes, but the container foundation remains the same.

Same application.

Different environments.

Why This Setup Becomes Repetitive

Dockerizing one Spring Boot application is useful experience.

Dockerizing your fifth one feels different.

Most projects need the same decisions:

Dockerfile structure
build optimization
Docker Compose setup
environment handling
production configuration
security defaults
deployment compatibility

None of these pieces are impossible.

But rebuilding them repeatedly slows down actually building the application.

Automating This Setup with SpringGen

SpringGen generates Spring Boot projects with a Docker-ready foundation:

optimized multi-stage builds
local Docker Compose configuration
database container setup
production environment structure
deployment-ready configuration

The generated project is normal Spring Boot code:

No runtime dependency

No vendor lock-in

Fully editable source code

Generate the foundation, then build your application on top.

Try SpringGen

Free CLI(Generate a Starter Spring Boot project locally):

npm install -g springgen
springgen init

GitHub:

springgen-dev / springgen

Generate & deploy a production-ready Spring Boot project with Docker, OAuth2, GitHub Actions CI/CD, and AWS EC2 — in minutes.

SpringGen — Generate Spring Boot Backends in Minutes 🚀

Generate production-ready Spring Boot backends instantly — Authentication, Database, Docker, CI/CD, and AWS EC2 deployment included.

👉 Try Free via CLI • 🚀 Upgrade to Pro

What is SpringGen?

Every new backend service starts the same way — same structure, auth setup database config, security hardening, Docker, and CI/CD pipeline. Most developers rebuild this from scratch or copy-paste from a previous project every single time.

SpringGen is built around that repeated workflow. Whether you are a freelancer spinning up a new client backend, a founder building an MVP, or a developer starting another microservice — run the CLI or web UI, get a consistent production-ready backend, and start writing business logic.

No copy-pasting. No forgotten configs. No "how did I set this up last time."

SpringGen uses a deterministic template/module engine to assemble tested Spring Boot project structures, configurations, and production-ready…

View on GitHub

App:

app.springgen.dev

Final Thoughts

Docker is not only a deployment tool.

It is a way to make application environments repeatable.

A good Docker setup helps developers build, test, and deploy with confidence.

Understanding Docker matters.

Recreating the same setup forever does not.

OAuth2 Login with JWT and Refresh Tokens in Spring Boot — The Setup You'll Rebuild Every Time

Yadrs — Sat, 13 Jun 2026 14:12:13 +0000

Most Spring Boot applications eventually need authentication.

And many teams rebuild the same foundation every time.

Add a login endpoint. Generate a token. Protect some APIs.
Then production arrives — and the real requirements show up.

A real backend often needs:

external identity providers
secure access tokens
refresh token rotation
user persistence
token expiration handling
protected APIs
logout support
environment-based secrets

This is where OAuth2 combined with JWT access tokens and refresh tokens becomes a common approach.

This guide walks through the architecture, moving parts, and decisions behind building a production-style authentication flow with Spring Security.

The Problem with Basic Token Authentication

A simple JWT authentication flow usually looks like this:

User logs in
      ↓
Backend validates credentials
      ↓
Backend creates JWT
      ↓
Frontend stores JWT
      ↓
JWT is sent with API requests

For small applications, this works.

But production systems quickly need more:

What happens when the JWT expires?

How does a user stay logged in?

How do you revoke access?

Where are user identities stored?

How do you support Google login?

This is why many applications move toward:

OAuth2 Login
      +
JWT Access Tokens
      +
Refresh Tokens

Understanding the Authentication Flow

A common production flow looks like this:

User
 ↓
Login with Google/GitHub
 ↓
OAuth2 Provider verifies identity
 ↓
Spring Security receives user info
 ↓
Backend creates application tokens
 ↓
Return:
   - short-lived access token
   - longer-lived refresh token

After login, the client does not call Google for every request.

Instead:

Client
 ↓
Authorization: Bearer JWT
 ↓
Spring Boot API
 ↓
JWT validation
 ↓
Protected resource

Your backend remains responsible for securing its own APIs.

Access Tokens vs Refresh Tokens

A common mistake is treating one JWT as enough.

A better pattern separates responsibilities.

Access Token

Purpose:

Authorize API requests

Characteristics:

short expiration time
sent with requests
stateless validation
contains limited claims

Example:

Expires in:
15 minutes

Refresh Token

Purpose:

Request a new access token

Characteristics:

longer lifetime
stored securely
persisted in database
can be revoked

Example:

Expires in:
7-30 days

Flow:

Access token expires
          ↓
Client sends refresh token
          ↓
Backend validates refresh token
          ↓
New access token issued

The user stays logged in without keeping permanent access tokens.

Typical Spring Boot Structure

A production authentication module usually introduces:

security/
├── JwtService           → creates and validates tokens
├── JwtAuthenticationFilter → intercepts requests before controllers
├── OAuth2SuccessHandler → handles post-login token generation
└── SecurityConfig       → wires the filter chain together

entity/
├── User
└── RefreshToken

repository/
├── UserRepository
└── RefreshTokenRepository

controller/
└── AuthController

Each component has a responsibility.

Spring Security Configuration

Spring Security becomes the entry point.

The configuration usually handles:

public endpoints
protected endpoints
OAuth2 login
JWT validation filters
CORS configuration
unauthorized responses

Conceptually:

Incoming request
        ↓
Security filter chain
        ↓
JWT filter
        ↓
Authentication context
        ↓
Controller

The goal is:

Controllers should not manually check tokens.

Security should happen before requests reach your business logic.

OAuth2 Success Handling

After a successful OAuth2 login:

Google authentication succeeds
          ↓
Spring Security receives user profile
          ↓
Find or create local user
          ↓
Generate application tokens
          ↓
Return tokens to client

The application usually stores:

User:
- id
- email
- provider
- provider id

RefreshToken:
- token
- expiry
- associated user

This lets your application own authorization decisions.

Token Refresh Flow

Refreshing authentication usually looks like:

POST /auth/refresh

Refresh token
       ↓
Validate token exists
       ↓
Check expiration
       ↓
Generate new JWT
       ↓
Return new access token

Important considerations:

expire old tokens
support logout
remove compromised refresh tokens
avoid unlimited token lifetime

Environment Configuration

Production authentication should avoid hardcoded secrets.

Common configuration:

JWT_SECRET

JWT_EXPIRATION

GOOGLE_CLIENT_ID

GOOGLE_CLIENT_SECRET

FRONTEND_REDIRECT_URL

These values should come from:

environment variables
deployment secrets
cloud secret managers

Never commit production credentials.

Common Production Improvements

After the basic flow works, teams often add:

Refresh Token Rotation

Instead of reusing refresh tokens:

Use refresh token
        ↓
Delete old token
        ↓
Create new token

This reduces risk if tokens leak.

Secure Cookies

Some applications store tokens using:

HttpOnly
Secure
SameSite
cookies

instead of browser storage.

The best choice depends on frontend architecture.

Rate Limiting

Authentication endpoints should be protected:

Examples:

/auth/login

/auth/refresh

to reduce abuse.

What Goes Wrong in Production

A few things that catch teams off guard:

Refresh tokens stored in localStorage are vulnerable to XSS.
HttpOnly cookies are safer but require careful CORS configuration.
Token expiration mismatches between frontend and backend
can cause confusing 401 errors that are hard to debug.
Refresh token rotation without proper cleanup can create
orphaned tokens that accumulate in your database.
Logout that only clears frontend storage is not a complete logout.
The refresh token may still remain valid until expiration.

Why This Setup Becomes Repetitive

OAuth2 authentication is not just adding a dependency.

A complete setup usually includes:

Spring Security configuration
OAuth2 handlers
JWT utilities
refresh token persistence
database entities
repositories
exception handling
environment configuration

None of these pieces are impossible.

But most projects rebuild a very similar foundation.

Automating This Setup with SpringGen

After you understand the architecture, rebuilding these files for every new project becomes repetitive.

SpringGen helps generate Spring Boot backend foundations with:

OAuth2 authentication setup
JWT access tokens
refresh token flow
database configuration
security structure
Docker setup
deployment configuration

Generated projects are normal Spring Boot applications:

No runtime dependency
No vendor lock-in
Fully editable source code

The goal is simple:

Spend less time rebuilding authentication infrastructure and more time building the application.

Try SpringGen

GitHub: https://github.com/springgen-dev/springgen

App: https://app.springgen.dev

Final Thoughts

Authentication is one of the first systems every backend needs.

A good authentication setup is not only about logging users in.

It is about creating a foundation that is secure, maintainable, and ready to evolve.

Understanding the pieces matters.

Repeating the same setup forever does not.

GDPR Compliance in a Spring Boot App — The Implementation Nobody Talks About

Yadrs — Thu, 11 Jun 2026 13:55:24 +0000

Most GDPR articles stop at cookie banners and privacy policies.

That is the visible layer. The part users see.

The harder part is what happens inside your backend — how you store
personal data, how you handle deletion requests, how you prove
compliance when someone asks.

I spent years implementing data privacy controls at an enterprise level.

This is the implementation side that most tutorials skip.

What GDPR Actually Requires From Your Backend

GDPR gives users specific rights over their personal data.

The ones that directly affect your Spring Boot backend:

Right to Access      → User can request all data you hold about them
Right to Erasure     → User can request deletion of their data
Right to Portability → User can request their data in a portable format
Right of Rectification → User can request correction of inaccurate data
Breach Notification  → You must notify users within 72 hours of a breach

Each of these is not just a policy decision. Each one requires actual code.

1. Know What Personal Data You Are Storing

Before writing any compliance code, you need a data inventory.

Personal data under GDPR includes anything that can identify a person — directly or indirectly:

Direct identifiers:
- name
- email address
- phone number
- IP address
- user ID

Indirect identifiers:
- device fingerprint
- location data
- behavioral data (clicks, sessions)
- combination of fields that together identify someone

Map every table in your database. For each column, ask:

Is this personal data?
Why are we storing it?
How long do we need it?
Who can access it?

This is your Record of Processing Activities (RoPA) — a GDPR requirement for most organizations.

If you cannot answer why you are storing a piece of data, you probably should not be storing it.

2. Classify Your Data at the Model Level

One practical approach is annotating your JPA entities to make PII visible in your codebase.

Create a simple annotation:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface PersonalData {
    String category() default "general";
    String purpose();
    boolean canBeDeleted() default true;
}

Use it on your entities:

@Entity
public class User {

    @Id
    private Long id;

    @PersonalData(purpose = "authentication", category = "contact")
    private String email;

    @PersonalData(purpose = "personalization", category = "contact")
    private String fullName;

    @PersonalData(purpose = "analytics", category = "technical", canBeDeleted = true)
    private String ipAddress;

    private String role; // not personal data
}

This does two things:

Makes PII visible to every developer reading the code
Gives you a foundation for automated compliance tooling later

It will not enforce anything on its own. But it documents intent in the place that matters — the code.

3. Implement the Right to Erasure

The right to erasure (right to be forgotten) is the most technically complex GDPR requirement for a backend developer.

When a user requests deletion, you have to decide between two approaches:

Hard delete   → Remove the record entirely from the database
Soft delete   → Anonymize the record, retain the row for audit/integrity

For most applications, hard deletion across all tables is impractical. Foreign key constraints, audit logs, financial records, and legal retention requirements all complicate it.

A more realistic approach is pseudonymization — replacing personal data with anonymized values while retaining non-personal data you have a legitimate reason to keep.

Example erasure service:

@Service
@Transactional
public class DataErasureService {

    private final UserRepository userRepository;
    private final AuditLogRepository auditLogRepository;

    public void eraseUser(Long userId) {

        User user = userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException(userId));

        // Anonymize personal fields
        user.setEmail("deleted-" + userId + "@anonymized.invalid");
        user.setFullName("Deleted User");
        user.setIpAddress(null);
        user.setPhoneNumber(null);
        user.setDeletedAt(Instant.now());
        user.setStatus(UserStatus.ERASED);

        userRepository.save(user);

        // Record the erasure for your audit log
        auditLogRepository.save(AuditLog.builder()
            .action("USER_ERASED")
            .subjectId(userId)
            .performedAt(Instant.now())
            .build());
    }
}

Important considerations:

Keep a record that erasure happened — not what was erased
Check for financial or legal retention obligations before deleting
Cascade the erasure to related services and tables
Do not forget logs — application logs often contain email addresses

4. Implement the Right to Access (Data Subject Access Request)

When a user requests all data you hold about them, you need to be able to produce it.

A data subject access request (DSAR) endpoint:

@RestController
@RequestMapping("/api/privacy")
public class PrivacyController {

    private final DataExportService dataExportService;

    @GetMapping("/export")
    public ResponseEntity<UserDataExport> exportMyData(
            @AuthenticationPrincipal UserDetails userDetails) {

        UserDataExport export = dataExportService.exportForUser(
            userDetails.getUsername()
        );

        return ResponseEntity.ok(export);
    }
}

The export service aggregates data across your tables:

@Service
public class DataExportService {

    public UserDataExport exportForUser(String email) {
        return UserDataExport.builder()
            .profile(userRepository.findByEmail(email))
            .transactions(transactionRepository.findByUserEmail(email))
            .preferences(preferenceRepository.findByUserEmail(email))
            .auditEvents(auditRepository.findByUserEmail(email))
            .exportedAt(Instant.now())
            .build();
    }
}

Return this as JSON or generate a PDF export depending on your use case.

Key things to include:

All profile data
All activity data you hold
Preferences and settings
How long you retain each type of data
Third parties you share data with

5. Consent Management

If you rely on consent as your legal basis for processing, you need to record it — not just collect it.

A consent record is not a checkbox in your UI. It is a timestamped, versioned record in your database.

@Entity
public class ConsentRecord {

    @Id
    @GeneratedValue
    private Long id;

    private Long userId;
    private String consentType;    // e.g. MARKETING, ANALYTICS
    private String consentVersion; // version of your privacy policy
    private boolean granted;
    private Instant recordedAt;
    private String ipAddress;
    private String userAgent;
}

Every time consent is given or withdrawn, you write a new record. You never update the old one.

This gives you an audit trail you can produce if your processing is ever challenged.

6. Data Retention — Automate the Cleanup

Keeping personal data longer than necessary can violate GDPR data minimization and storage limitation principles.

Define retention periods for each data category and automate deletion using Spring Batch or a scheduled job:

@Component
public class DataRetentionJob {

    // Delete inactive user data after 2 years
    @Scheduled(cron = "0 0 2 * * SUN")
    @Transactional
    public void purgeExpiredUserData() {

        Instant cutoff = Instant.now().minus(730, ChronoUnit.DAYS);

        List<User> expiredUsers = userRepository
            .findInactiveUsersBefore(cutoff);

        expiredUsers.forEach(user -> dataErasureService.eraseUser(user.getId()));

        log.info("Data retention job completed. Processed {} users.", expiredUsers.size());
    }
}

Document your retention periods somewhere accessible:

User profiles         → 2 years after last login
Transaction records   → 7 years (legal requirement)
Application logs      → 90 days
Consent records       → Duration of relationship + 1 year
Anonymized analytics  → Indefinite (no longer personal data)

7. Audit Logging for Compliance

You need to be able to answer: who accessed what personal data, and when.

A simple audit log entity:

@Entity
public class AuditLog {

    @Id
    @GeneratedValue
    private Long id;

    private String action;        // DATA_ACCESSED, DATA_ERASED, CONSENT_GIVEN
    private Long subjectId;       // the user whose data was affected
    private Long actorId;         // who performed the action
    private String resourceType;  // USER_PROFILE, TRANSACTION, etc.
    private Instant performedAt;
    private String ipAddress;
}

Write audit events for:

Any access to personal data via API
All erasure requests and outcomes
All consent changes
Any data exports
Any admin access to user records

This audit trail is what you produce during a regulatory investigation or a user complaint.

Security configuration is also part of privacy engineering.

Access controls should ensure:

users only access their own data
admin actions are restricted
sensitive endpoints require authentication
authorization checks are tested

Authentication is only the first step.
Correct authorization is what protects personal data.

8. What About Application Logs?

This is the most commonly overlooked GDPR issue in Spring Boot applications.

Application logs almost always contain personal data — email addresses in authentication logs, user IDs in request logs, IP addresses in access logs.

Two practical steps:

Step 1 — Mask personal data in logs:

public class PersonalDataMaskingConverter extends ClassicConverter {

    private static final Pattern EMAIL_PATTERN =
        Pattern.compile("[a-zA-Z0-9._%+\\-]+@[a-zA-Z0-9.\\-]+\\.[a-zA-Z]{2,}");

    @Override
    public String convert(ILoggingEvent event) {
        String message = event.getFormattedMessage();
        return EMAIL_PATTERN.matcher(message).replaceAll("****@****.***");
    }
}

Step 2 — Set a log retention policy:

Logs should not be retained indefinitely. 30 to 90 days is a common default.
Configure this in your log aggregation system — CloudWatch, Splunk, or whatever you use.

The Part Nobody Warns You About

Building the compliance controls is the straightforward part.

The harder part is maintaining them as your application grows.

New developers join and add new fields without thinking about PII.
A new service gets added that logs user data in a new format.
A third-party integration starts receiving personal data without a data processing agreement.

The controls that matter most are not technical — they are process:

Code review checklist that asks "does this field contain personal data?"
Data processing agreements with every third-party service you send data to
A documented process for handling erasure requests within 30 days
A documented process for breach notification within 72 hours
Regular review of what data you are actually storing vs what you documented

The annotation approach from step 2 helps with this — it makes PII visible in code reviews.

But there is no substitute for making compliance part of your engineering culture, not just your legal documentation.

Summary

GDPR compliance in a Spring Boot backend comes down to six concrete things:

1. Know what personal data you store and why
2. Implement erasure — anonymize or delete on request
3. Implement data export — produce user data on request
4. Record consent with timestamps and versions
5. Automate data retention — delete what you no longer need
6. Audit log all access and changes to personal data

None of these are impossible to build.

The challenge is building all of them, keeping them working as your application grows,
and making sure new features respect the same rules.

Starting With a Production Foundation

If you are starting a new Spring Boot backend, SpringGen generates the security scaffolding, structured logging configuration, and production-ready defaults that give you a solid foundation before you write your first line of business logic.

The compliance layer on top of that foundation is still your responsibility.

But starting with clean structure, proper security defaults, and production configuration in place removes one layer of things to get right from scratch.

GitHub: https://github.com/springgen-dev/springgen

App: https://app.springgen.dev

This article reflects practical implementation patterns for GDPR compliance in Spring Boot applications.
It is not legal advice. Consult a qualified lawyer or DPO for your specific compliance obligations.

Deploying Spring Boot to AWS EC2 with Docker and GitHub Actions — The Repeatable Way

Yadrs — Tue, 09 Jun 2026 15:25:09 +0000

Deploying a Spring Boot application to AWS EC2 is straightforward once you've done it.

Getting there the first time — and repeating the setup on your next few projects — is where the real cost appears.

A production deployment is usually not just about running a JAR file.

For a real-world backend, deployment often involves:

separating local and production configuration
building the application consistently
packaging it with Docker
managing environment variables and secrets
connecting to an EC2 instance
restarting the app safely
automating the process after every push

This guide walks through the deployment workflow at a high level, the decisions involved, and why this setup becomes repetitive across projects.

The goal is not to hide the details. You should understand your deployment pipeline.

The real pain starts when you have to rebuild the same foundation again and again.

The Deployment Flow

A typical Spring Boot EC2 deployment with GitHub Actions looks like this:

Push to main branch
        ↓
GitHub Actions runs cd.yml
        ↓
GitHub Actions connects to EC2 using SSH
        ↓
EC2 pulls the latest code
        ↓
Production environment variables are prepared
        ↓
Deployment script runs
        ↓
Docker rebuilds and restarts the application

At a high level, the moving parts are:

Spring Boot app
Docker
GitHub Actions
AWS EC2
Environment variables
Deployment script

Each piece is simple enough on its own.

The complexity comes from wiring them together correctly and repeating that setup for every new backend.

1. Separate Local and Production Configuration

A production-ready Spring Boot project usually needs different configuration for local development and production.

For example:

src/main/resources/
├── application.yml
└── application-prod.yml

Local configuration may use local Docker containers.

Production configuration should rely on environment variables.

Example production config pattern:

spring:
  datasource:
    url: ${SPRING_DATASOURCE_URL}
    username: ${SPRING_DATASOURCE_USERNAME}
    password: ${SPRING_DATASOURCE_PASSWORD}

server:
  port: ${SERVER_PORT:8080}

The important principle:

Do not hardcode production secrets in source code.

Use environment variables, GitHub Secrets, AWS Secrets Manager, or another secret management approach.

2. Add Docker Packaging

Docker gives the application a consistent runtime environment.

A Spring Boot deployment usually needs:

Dockerfile
docker-compose.yml
docker-compose.prod.yml

The Dockerfile packages the Spring Boot application.

The Compose files help define how the app runs locally or in production.

A simplified Docker flow looks like:

Build JAR
        ↓
Build Docker image
        ↓
Run container
        ↓
Expose app on port 8080

The exact Dockerfile can vary depending on:

Java version
Gradle vs Maven
multi-stage build preference
whether you want smaller runtime images
whether the app needs extra OS packages

The key is consistency.

Once Docker is in place, the app runs the same way every time.

3. Prepare the EC2 Instance

Before GitHub Actions can deploy anything, the EC2
instance needs to be ready to receive it.

An EC2 deployment needs a server with the required runtime tools installed.

At minimum, the EC2 instance usually needs:

Git
Docker
access to the repository
an SSH user
firewall/security group allowing app traffic
environment configuration for production

The deployment process should avoid manually copying files whenever possible.

Instead, the EC2 instance can pull the latest code from the repository and run a deployment script.

That keeps the deployment repeatable.

4. Use GitHub Actions as the Deployment Trigger

GitHub Actions becomes the automation layer.

The workflow usually does this:

Checkout repository
        ↓
Connect to EC2 over SSH
        ↓
Pull latest code on EC2
        ↓
Create or update production environment variables
        ↓
Run deployment script

A simplified workflow shape looks like this:

name: Deploy Spring Boot

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to EC2
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            cd my-app
            git pull origin main
            ./scripts/deploy-ec2.sh

This is intentionally simplified.

A real workflow may also handle:

private repositories
GitHub personal access tokens
production .env creation
Docker installation checks
branch-specific deployments
build validation
rollback strategy

5. Use a Deployment Script on EC2

Instead of putting all deployment logic directly inside GitHub Actions, it is cleaner to keep the actual app deployment logic in a script inside the project.

Example:

scripts/deploy-ec2.sh

A deployment script typically handles:

stopping the existing container
removing old containers/images when needed
rebuilding the Docker image
starting the updated container
loading production environment variables
keeping deployment commands consistent

A simplified script flow:

Read environment config
        ↓
Stop existing container
        ↓
Build latest Docker image
        ↓
Start new container
        ↓
Verify app is running

This is useful because the script can be used in two ways:

Automated:
GitHub Actions runs it during CI/CD

Manual:
SSH into EC2 and run it directly

That gives flexibility without duplicating deployment logic.

6. Manage Production Environment Variables

Production deployments usually need a .env.prod or equivalent environment configuration.

Typical values include:

APP_NAME
SERVER_PORT
SPRING_PROFILES_ACTIVE

SPRING_DATASOURCE_URL
SPRING_DATASOURCE_USERNAME
SPRING_DATASOURCE_PASSWORD

JWT_SECRET
OAUTH_CLIENT_ID
OAUTH_CLIENT_SECRET

CORS_ALLOWED_ORIGINS

There are two common approaches.

Option A — GitHub Actions creates the production env file

GitHub Secrets store sensitive values.

During deployment, GitHub Actions writes those secrets into .env.prod on the EC2 instance.

This keeps secrets out of source code.

Option B — Create `.env.prod` manually once on EC2

For a simpler setup, you can SSH into EC2 and create the production env file once.

Then future deployments reuse it.

This is useful for smaller projects or manual deployments.

7. What This Looks Like End-to-End

The complete deployment system looks like this:

Developer
   ↓
Pushes code to main
   ↓
GitHub Actions starts
   ↓
SSH connection to EC2
   ↓
EC2 pulls latest code
   ↓
Production env config is prepared
   ↓
scripts/deploy-ec2.sh runs
   ↓
Docker rebuilds app
   ↓
Old container is replaced
   ↓
Spring Boot app runs on EC2

This is a practical setup for:

side projects
MVPs
internal tools
freelance client backends
small SaaS applications

It is not the only way to deploy Spring Boot.

But it is a useful middle ground between:

Manual SSH deployment

and:

Full Kubernetes / enterprise platform setup

Why This Becomes Repetitive

The first time you set this up, it is a learning exercise.

The third or fourth time, it becomes repetitive.

Every new Spring Boot backend needs similar decisions:

project structure
Docker setup
production config
deployment workflow
CI/CD files
environment variables
security defaults
logging configuration

None of these pieces are impossible.

But wiring them together correctly takes time.

And if you are building multiple projects, client backends, SaaS ideas, or microservices, that setup cost repeats.

Automating Repetitive Backend Setup

This is the kind of repetitive backend setup that SpringGen is designed to automate.

SpringGen creates a ready-to-customize Spring Boot foundation with:

layered backend structure
database configuration
authentication scaffolding
Docker setup
GitHub Actions workflows
AWS EC2 deployment automation
security hardening
logging configuration

The goal is not to replace understanding Spring Boot or DevOps.

The goal is to remove the repetitive setup after you already know what kind of backend foundation you want.

Generated projects are standard Spring Boot code:

No generator runtime dependency
No framework lock-in
No frontend opinions

You generate the project, then own and modify the code like any normal Spring Boot application.

Try SpringGen

GitHub: https://github.com/springgen-dev/springgen

App:

app.springgen.dev

Demo video:

Final Thoughts

A good deployment pipeline is not just about pushing code to a server.

It is about making deployment predictable, repeatable, and easy to maintain.

You can absolutely build every piece of this manually — and understanding how it works is important.

But after you have configured the same Docker setup, CI/CD workflow, environment files, and deployment scripts across multiple projects, the setup itself becomes the repetitive part.

That repetition is what SpringGen is designed to remove.

Spend less time rebuilding the foundation, and more time building the application.