Iced-Latte: a Java 25 Spring Boot backend for a coffee marketplace

A marketplace backend that exists to teach

Iced Latte is described as a non-profit sandbox project started in 2022 as a private pet project, later opened to the community so that junior engineers, students and mentees could get practical experience in a real tech project with processes similar to those in actual tech teams. The first participants were students, subscribers to a Telegram channel, and mentees from ADPList and Women In Tech. That origin explains the shape of everything else. The description calls it a production-grade Java 25 and Spring Boot 4 backend for a coffee marketplace, and the feature list is the one you would expect from a real commerce product: authentication, catalog, cart, orders, payments, reviews, file storage, observability and cloud-ready infrastructure. But the stated purpose is the point. The audience is a developer who wants to see how a team works, not a business looking for a turnkey commerce system, and the repository makes that trade explicit by hosting a live demo, a getting started guide, API specifications and a labelled set of good first issues.

Three repositories so three kinds of contributor can work

The repository ecosystem table is the first thing a newcomer should read, because it explains how contributions are meant to be divided. The project is split into three focused repositories so contributors can work on backend, frontend or QA independently. The backend repository, this one, holds Java 25, Spring Boot 4, PostgreSQL, Redis, MinIO, Stripe and OpenAPI, and is aimed at backend engineers, Java learners and API contributors. The frontend repository holds the customer-facing marketplace web application and is aimed at frontend engineers, UI contributors and React learners. The QA repository holds test automation, quality workflows and end-to-end coverage for QA engineers, test automation learners and release-quality contributors. That division is a deliberate piece of project design. A single monolithic repository would make a first contribution hard to scope, and a learner who wants to write tests would have to navigate a Java codebase to do it. Here the smallest unit of contribution is a whole layer.

The stack behind the coffee shop

The technology list is visible in the compose file and the environment template rather than in prose, which makes the real architecture easy to read. The application itself is a Java 25 Spring Boot 4 service built with Maven, with Spring Data JPA for persistence, Log4j2 for logging, Lombok in the dependency tree, JWT for tokens and Stripe for payments. Alongside it sit the infrastructure pieces, PostgreSQL as the primary database, Redis for caching and token and session features, and MinIO as the S3-compatible object store that backs file storage. The compose file gives each of them its own container with a named volume, so postgres-data, redis-data and minio-data survive a restart. The environment template adds the application settings on top of that, with an app server port of 8083, a dev profile, and a datasource block that matches the postgres container exactly, including the SSL mode left off for the local database.

Running the stack locally in two commands

The environment template is written with the contributor in mind, and the header states that all the values in it work out of the box for local development. Stripe, Google OAuth, email, AI, Kafka, Turnstile and remote observability are disabled by default, so a localhost run needs no production credentials at all. The template documents the two commands that matter:

#   docker compose --env-file .env.example up -d postgres redis minio minio-init
#   set -a && source .env.example && set +a && mvn spring-boot:run

The first starts the infrastructure services you need, the database, the cache and the object store with its initialisation step, and the second exports the environment and runs the Spring Boot application from source, either from the command line or from IntelliJ. The datasource block inside the template lines up with the compose service names and defaults:

DATASOURCE_HOST=localhost
DATASOURCE_PORT=5432
DATASOURCE_NAME=postgres
DATASOURCE_USERNAME=postgres
DATASOURCE_PASSWORD=postgres

The dev profile is chosen by SPRING_PROFILES_ACTIVE=dev, and the template explains that this contributor default turns on the Swagger UI, debug level application logs and Liquibase reseeding on restart, which is why a fresh checkout has data in it and why restarting the app resets the schema. The compose file also checks the health of the services rather than just starting them, with the postgres healthcheck verifying both server readiness and the target database name so that startup ordering matches what the application actually connects to.

The Dockerfile is a cache exercise as much as a build

The Dockerfile is worth reading because its comments explain the reasoning, and the reasoning is about layer caching rather than about the application. The build stage uses a Maven image with Temurin 25 on Alpine and produces the executable Spring Boot JAR, and the fat JAR is built in a separate stage so the runtime image stays small. The copy order is deliberate. The POM and the Maven JVM configuration are copied first, so that Docker builds use the same JDK module flags as local builds, then the Maven dependency cache is primed with a go-offline step run through a BuildKit cache mount, with a fallback that echoes a message and continues to the real package step if the warmup misses something. The application sources are copied only after that warmup, so source edits do not invalidate the dependency layer. The extract stage then splits the Spring Boot JAR into layers with a Temurin 25 JRE on Alpine, because Spring Boot can split the executable JAR into layers and let Docker reuse the unchanged dependency layers between builds. The build profile is passed in as a build argument so the same image definition covers different profiles.

Quality gates, API specs and the security scaffolding

The badges in the README describe a project that has automated the boring parts of its own process. There is a continuous integration workflow, a SonarCloud quality gate badge reporting the alert status, and a Codecov coverage badge. The topics list adds SonarQube, Log4j2, Postman and Kubernetes to the stack, and the repository root contains api-test.sh, a coverage configuration file and a seed/ directory for populating a database. API specifications live under src/main/resources/api-specs, so the contract is versioned in the repository rather than in a separate tool. The security scaffolding is just as visible. There is a .gitguardian.yml, which is a secret-scanning configuration, a SECURITY-HARDENING-IDEAS.md document, an AGENTS.md alongside CLAUDE.md, CODEX.md and AMAZONQ.md for coding agents, and a NOTICE file, which is what a project keeping Apache-style attribution conventions looks like. The presence of all of this is the argument the project makes about itself: a learning environment that behaves like a real one.

A personal evaluation licence, not an open source grant

This is the point to slow down on, and it is the one place where the repository's own presentation and its legal reality diverge. The licence badge in the README reads Personal Evaluation 2026, and the repository's licence field is recorded as a custom licence that GitHub cannot categorise, with the terms in the LICENSE file. There is a RELICENSING.md document in the root, which suggests the position has been revisited, and the README asks readers to give the project a star because it helps contributors discover the ecosystem, a request that sits oddly next to a licence that is not an open source grant in the usual sense. Nothing here is a legal opinion, but the practical question is simple. If you want to run this as a commercial service, to put it inside a product, or to build on it in an employer context, you need to read the LICENSE file and, if the terms do not cover you, ask the maintainers. The versioning tells the same kind of story. There is a single release, v1.0.0 labelled Pre-MVP Release and dated 2024-07-01, the default branch is development rather than main, and the last push to that branch was on 2026-09-28, so the tag is a starting point and the branch is where the work has continued.

Editorial conclusion

Iced-Latte suits a junior Java developer or a mentor who wants a real-shaped project to work on, complete with a compose file, an env template, API specs and CI, and it suits a team that wants a starting point for a small marketplace backend. It is the wrong base for a commercial product, because the recorded licence is a personal evaluation licence and the README asks for a star rather than a licence grant. Before building on it, read the LICENSE file and the RELICENSING.md document, and treat the single pre-MVP release tag from July 2024 as a starting point rather than a stable version, since the development branch is where the work has continued since.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Sunagatov/Iced-Latte on GitHub