Everything this week has been building to this chapter. You have an image that runs your whole backend, and a promise from the Docker Compose chapter to keep: in the cloud, your app becomes one deployed container that connects to a managed database service. The Compose file stays on your laptop.
This is what you are about to build:
At the end of this chapter, your API service answers requests from anyone, anywhere on the internet.
You could rent a virtual machine, install Docker on it, and run your container yourself. That is a real option, and now you understand every step it would involve. But then you are responsible for the server: updates, HTTPS certificates, restarting crashed apps at 3 AM.
A PaaS (Platform as a Service) takes that over: you bring the container, the platform brings servers, HTTPS, restarts and a public URL. That is the right trade for us — this track is about your application, not about server administration.
We chose to use a simple and free stack:
<aside> 💭
Railway, Fly.io, DigitalOcean, and the big clouds (AWS, Azure, GCP) all offer the same thing with different dashboards. Learn the concepts here and you can switch platforms in an afternoon.
</aside>
Neon will show a full connection URL, you may need to extract the credentials from there separately. Here is the format of the full connection URL:
postgresql://<USERNAME>:<PASSWORD>@<HOSTNAME>/<DB_NAME>?sslmode=require&channel_binding=require
Dockerfile and .dockerignore to a GitHub repository.Dockerfile and selects the Docker runtime.Now watch the logs: Render runs your multi-stage docker build on its own machines and starts the container. From now on, every push to your branch triggers a new build and deploy - how cool is that?
Your deployed container needs to know where the database is. Same mechanism as in the Compose chapter — SPRING_DATASOURCE_* environment variables override application.yaml — but the values now point at Neon, and they live in Render's Environment tab.
One conversion trips everyone up. Neon gives you one Postgres-style string; Spring wants a JDBC URL plus separate credentials:
Neon gives you:
postgresql://hyf:[email protected]/neondb?sslmode=require
You configure in Render:
SPRING_DATASOURCE_URL = jdbc:postgresql://ep-xxx.eu-central-1.aws.neon.tech/neondb?sslmode=require
SPRING_DATASOURCE_USERNAME = hyf
SPRING_DATASOURCE_PASSWORD = password
PORT = 8080
So: add jdbc: in front, move the user and password out of the URL into their own variables, and keep ?sslmode=require — Neon only accepts encrypted connections.
The extra PORT variable tells Render which port your container listens on. Render routes public traffic to the port named in PORT; our Spring Boot app listens on 8080.
<aside> ❗
This dashboard is where production secrets live — not in Git, not in the image, not in application.yaml. This is why we never hardcoded credentials all week. Your properties file says localhost, Compose said db, Render says Neon: three environments, one unchanged image.
</aside>
When the deploy turns Live, your service has a public URL: https://<your-service>.onrender.com. Open an endpoint in the browser, fire your Postman collection at it — and then open it on your phone. Not localhost. The internet.
<aside> 🎉
Congratulations - this is a big milestone! Your project is now live 24/7 in the cloud and can be accessed by anyone around the world.
</aside>
How does Render know your app is actually working — not crashed, not still starting? It asks. A health check is an endpoint the platform calls regularly; while it fails, the platform holds traffic back or restarts the container.
You can write one with what you already know:
@RestController
public class HealthController {
@GetMapping("/health")
public String health() {
return "OK";
}
}
Then, in your Render service settings, set the Health Check Path to /health. Render now probes it and only considers a deploy successful once it answers.
<aside> 💡
In real Java projects this endpoint usually comes from Spring Boot Actuator, a standard module that provides /actuator/health including database checks. You will meet it on the job — and now you know exactly what it does under the hood.
</aside>
The Logs tab of your Render service is docker logs for the cloud: build output, Spring Boot startup, every request, every stack trace — streamed live.
The debugging reflex stays the same as it was locally: deploy failed, app crashed, endpoint misbehaves? Logs first. The reason is almost always in there — a typo in an environment variable, a failed database connection, an exception at startup.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.