Prashant Sharma Official

Part 9 of 10 of Building Instagram's Authentication Backend . If you're just joining, the repo is here and you can catch the earlier parts on the YouTube playlist . Eight parts of code, zero runs By the end of part 8, every layer of this backend existed: DTOs, exceptions, entities, repositories, five services, a security filter chain and a controller. And I had never started the application. Not once. Everything so far was code I'd reasoned through and believed would work. This part is where that belief gets tested. We containerize the app, put Postgres, Redis and a fake mail server next to it, and bring all four up with one command. It did not work the first time, so this post is the real debugging session, with each bug, its symptom and its fix. If you're containerizing your own Spring Boot app, there's a good chance you'll hit at least one of these. In this post: A multi-stage Dockerfile for Spring Boot, line by line A docker-compose.yml ...

There is one line in almost every Spring Boot tutorial that runs flawlessly on your laptop and slowly corrupts your database in production: spring : jpa : hibernate : ddl-auto : update # works on your laptop, quietly rewrites prod With ddl-auto: update , Hibernate looks at your entities on every startup and alters the live schema to match them. No migration file. No version. No review. No rollback. Two developers add different fields, deploy in a different order, and now staging and production have quietly diverged — and the day one of those "updates" needs to drop a column, Hibernate will happily take your data with it. In Episode 5 of Building Instagram's Authentication Backend , we do the opposite. The database is not something Hibernate improvises at boot — it is a versioned artifact, checked into git, owned by Flyway . We build the persistence layer in three deliberate steps: the SQL migration , then the JPA entities , then the Spring Data r...