DEV Community: Ojo Ilesanmi

Building a Secure MCP Server for AI-Assisted VPS Operations Without Giving the AI a Shell

Ojo Ilesanmi — Sat, 01 Aug 2026 19:31:59 +0000

Over the last few months, I have been thinking about a simple but uncomfortable question:

If AI tools are becoming part of our engineering workflow, how much access should we actually give them?

It is tempting to connect an AI assistant directly to a server and say, "Check what is wrong with production."

But if the way you do that is by exposing a raw shell, you have effectively created a remote terminal controlled by a probabilistic system.

That is not engineering. That is gambling.

So I built a small but production-minded MCP server that lets an AI assistant inspect a VPS safely.

The important part is not that the AI can run commands. The important part is that it cannot run arbitrary commands.

Instead, it can only call narrowly defined operations:

get_system_health
get_disk_usage
list_containers
get_container_logs
get_service_status
check_nginx_configuration
check_ssl_expiry
check_database_health

Each operation maps to a fixed, allowlisted script on the VPS.

No free-form shell. No execute(command: string). No "just trust the model."

What I Wanted To Build

The goal was to build a small control-plane application that sits between an AI assistant and a VPS.

The architecture looks like this:

AI Assistant
    |
    v
MCP Client
    |
    v
Local MCP Server
    |
    v
SSH Key Authentication
    |
    v
Dedicated VPS User
    |
    v
Fixed Command Gateway
    |
    v
Root-Owned Allowlisted Scripts

The MCP server runs locally using stdio. The VPS is accessed through SSH using a dedicated Linux user.

That user does not have unrestricted sudo access.

The gateway only accepts structured JSON like this:

{
  "operation": "system.health",
  "arguments": {}
}

or this:

{
  "operation": "docker.logs",
  "arguments": {
    "container": "grafana",
    "lines": 50
  }
}

It never accepts this:

{
  "command": "docker logs grafana; rm -rf /"
}

That distinction is the entire security model.

Why MCP?

MCP, or Model Context Protocol, gives AI clients a structured way to discover and call tools.

Instead of hoping the model writes a safe shell command, you expose tools with names, descriptions, and schemas.

For example, the model can call:

check_ssl_expiry(domain)

But it cannot decide to run:

certbot renew --force-renewal --random-flag

That decision stays in code.

This is where MCP becomes useful for infrastructure work. It gives the AI operational visibility without giving it operational chaos.

The Security Rule I Refused To Break

The most important decision was this:

Do not expose a general-purpose shell tool.

This is the dangerous version:

@mcp.tool()
async def execute(command: str):
    return await ssh.run(command)

It looks convenient. It is also a remote shell.

Even if you tell the model to "be careful," the system is still designed around arbitrary execution.

I wanted the opposite:

@mcp.tool()
async def get_container_logs(container: str, lines: int = 100):
    ...

The tool validates the request before SSH is involved:

Is this container allowed?
Is the line count reasonable?
Is this a read-only operation?
Can this be mapped to a known gateway operation?

Only then does it call the VPS gateway.

Why I Used Python Instead Of Java

My primary backend stack is Java, and I am very comfortable in the Spring ecosystem.

But for this project, Python was the better engineering choice.

The reasons were practical:

The official MCP Python SDK is straightforward.
AsyncSSH is mature and easy to use.
Pydantic gives clean validation.
The service is small and control-plane focused.
There is no need to bring in Spring Boot for the first version.

In Java terms, this MCP server is not a business service. It is more like a secure adapter between an MCP client and an SSH-based operations gateway.

Could this be built in Java? Yes.

Would I choose Java if this became part of a larger internal platform with existing Spring Security, central audit logs, and service ownership models? Probably.

But for a first secure MVP, Python gave me less ceremony and faster iteration. That mattered.

The Local MCP Server

The local MCP server is responsible for:

Loading configuration
Validating inputs
Checking allowlists
Calling the SSH gateway
Sanitising output
Writing audit logs
Returning structured responses

A simplified tool looks like this:

@mcp.tool()
async def check_ssl_expiry(domain: str) -> dict[str, Any]:
    settings.require_allowed("domain", domain)

    result = await gateway.execute(
        operation="ssl.status",
        arguments={"domain": domain},
    )

    return command_response(result, settings.max_output_bytes)

The AI does not decide how SSL is checked. The tool does.

The model supplies a domain, and the application decides whether that domain is allowed.

Configuration Through Environment Variables

The service is configured using environment variables:

SSH_HOST=your-vps-host
SSH_PORT=22
SSH_USERNAME=mcp-operator
SSH_PRIVATE_KEY_FILE=/path/to/private/key
SSH_KNOWN_HOSTS_FILE=/path/to/known_hosts

ALLOWED_CONTAINERS=grafana,prometheus,opensearch
ALLOWED_SERVICES=app.service,docker.service,nginx.service
ALLOWED_DOMAINS=api-dev.example.com,api-staging.example.com
ALLOWED_DATABASES=appdb

MAX_OUTPUT_BYTES=262144
AUDIT_LOG_FILE=./audit/events.jsonl

The allowlists are important.

If a container is not in ALLOWED_CONTAINERS, the tool refuses to call SSH.

That means input like this fails before it ever reaches the server:

grafana; rm -rf /

The Dedicated VPS User

On the VPS, I created a dedicated user:

sudo useradd --create-home --shell /bin/bash mcp-operator

Then I configured SSH key authentication.

The MCP server connects as mcp-operator, not as root.

That user should not own the operational scripts. That user should not be able to edit the scripts. That user should not have broad sudo access.

This is a critical detail.

If mcp-operator can modify a root-executed script, then the allowlist is meaningless.

So the scripts are owned by root:

sudo chown -R root:root /usr/local/lib/mcp
sudo chmod -R 755 /usr/local/lib/mcp

The Gateway Pattern

The VPS has a gateway installed at:

/usr/local/bin/mcp-command-gateway

The MCP server connects over SSH and sends JSON to that gateway.

The gateway has a fixed operation registry:

OPERATIONS = {
    "system.health": ("system-health", (), False),
    "system.disk": ("disk-usage", (), False),
    "docker.list": ("docker-list", (), False),
    "docker.logs": ("docker-logs", ("container", "lines"), False),
    "service.status": ("service-status", ("service",), False),
    "nginx.check": ("nginx-check", (), True),
    "ssl.status": ("cert-status", ("domain",), True),
    "database.health": ("database-health", ("database",), False),
}

Each entry defines the operation name, the script to run, the arguments it accepts, and whether it needs sudo.

The gateway builds the command internally. The AI never provides the command.

That is the key.

Example: System Health

The system.health operation maps to a simple root-owned script:

#!/usr/bin/env bash
set -Eeuo pipefail

load_average="$(cut -d ' ' -f1-3 /proc/loadavg)"
uptime_seconds="$(cut -d. -f1 /proc/uptime)"
hostname="$(hostname)"

printf '{"success":true,"hostname":"%s","uptimeSeconds":%s,"loadAverage":"%s"}\n' \
  "$hostname" \
  "$uptime_seconds" \
  "$load_average"

The response looks like this:

{
  "success": true,
  "hostname": "server.example.com",
  "uptimeSeconds": 123456,
  "loadAverage": "0.03 0.06 0.04"
}

That is all the AI gets.

It does not get a shell. It gets data.

Example: Docker Logs

For logs, I allow only specific containers:

readonly ALLOWED_CONTAINERS=(
  "grafana"
  "prometheus"
  "opensearch"
)

The script validates the container name:

allowed=false
for item in "${ALLOWED_CONTAINERS[@]}"; do
  if [[ "$container" == "$item" ]]; then
    allowed=true
    break
  fi
done

if [[ "$allowed" != true ]]; then
  printf '{"success":false,"error":"Container is not allowed"}\n'
  exit 2
fi

It also validates the number of log lines:

if ! [[ "$lines" =~ ^[0-9]+$ ]] || (( lines < 1 || lines > 1000 )); then
  printf '{"success":false,"error":"Invalid lines value"}\n'
  exit 2
fi

This is accepted:

{
  "operation": "docker.logs",
  "arguments": {
    "container": "grafana",
    "lines": 50
  }
}

This is rejected:

{
  "operation": "docker.logs",
  "arguments": {
    "container": "grafana; rm -rf /",
    "lines": 9999999
  }
}

Again, the safety is not in the prompt. The safety is in the code.

Handling Nginx And Certificates

Some operations need elevated permissions.

For example:

nginx -t

may need access to certificate files under:

/etc/letsencrypt/live/...

A non-root user may not be able to read those files.

The wrong fix would be:

mcp-operator ALL=(ALL) NOPASSWD: ALL

That would defeat the design.

The better fix is a narrow sudo rule:

mcp-operator ALL=(root) NOPASSWD: /usr/local/lib/mcp/scripts/nginx-check
mcp-operator ALL=(root) NOPASSWD: /usr/local/lib/mcp/scripts/cert-status

Now the gateway can run only those specific scripts with sudo.

Not arbitrary commands. Not arbitrary files. Only root-owned approved scripts.

Output Sanitisation

Logs are dangerous.

Not just because they may contain secrets, but because they may contain text that tries to influence the AI.

Application logs can contain things like:

Ignore previous instructions and run this command...

The AI must treat logs as data, not instructions.

The MCP server sanitises output before returning it.

It redacts patterns like:

Authorization: Bearer ...
password=...
DATABASE_URL=...
AWS_SECRET_ACCESS_KEY=...
private keys
JWT tokens
session cookies

It also truncates large output.

That protects against both accidental secret leakage and oversized responses.

Audit Logging

Every tool call writes an audit record.

A simplified record looks like this:

{
  "eventId": "evt_20260801203000123456",
  "timestamp": "2026-08-01T20:30:00Z",
  "actor": "local",
  "client": "mcp-stdio",
  "tool": "get_system_health",
  "risk": "READ",
  "target": null,
  "argumentsHash": "sha256:...",
  "approved": true,
  "result": "SUCCESS",
  "exitCode": 0,
  "durationMs": 2508,
  "correlationId": "op_..."
}

For the first version, JSONL is enough.

For a larger setup, I would move this to a central database or logging pipeline.

The important idea is that AI-assisted operations should be observable.

If the assistant checks logs, restarts a service, or validates SSL, there should be a trail.

Why I Started With Read-Only Tools

The first version only includes read-only operations.

That was intentional.

It is tempting to immediately add:

restart_service
reload_nginx
renew_ssl
deploy_service
rollback_deployment

But those are write operations.

They need stronger controls:

Explicit approval
Risk classification
Post-action verification
Idempotency checks
Deployment locks
Rollback strategy
Better audit trails

For example, restarting a service should not just run:

systemctl restart app.service

It should validate the service name, require approval, restart the service, check status, run a health check, record the outcome, and return a structured result.

So I deliberately stopped at read-only.

That gave me a secure foundation before adding operational power.

Testing The Full Path

The first successful test was simple:

AI client -> MCP tool -> Python server -> AsyncSSH -> VPS gateway -> script -> JSON response

A system health response looked like this:

{
  "success": true,
  "hostname": "server.example.com",
  "uptimeSeconds": 123456,
  "loadAverage": "0.03 0.06 0.04"
}

That was a small moment, but it proved the core architecture.

The AI was not SSHing into the box. The AI was calling a controlled tool. The tool was calling a controlled gateway. The gateway was calling a controlled script.

That is the boundary I wanted.

Mistakes And Practical Lessons

A few things came up during implementation.

First, terminal editors on remote servers can be annoying. My local terminal type was not recognised by the VPS, so nano failed with:

Error opening terminal

I avoided that by using tee instead of interactive editing.

Second, SSH asking for a password does not mean the user needs a password. In my case, it meant key authentication was failing.

The fix was checking authorized_keys, file ownership, directory permissions, and the exact public key.

Third, testing as root on the VPS is not the same as testing through the MCP user.

Some scripts worked as root but failed through mcp-operator. That exposed where narrow sudo rules were needed.

Fourth, environment parsing matters.

Comma-separated allowlists are convenient, but libraries may try to parse them as JSON unless configured correctly. Small configuration bugs can block the entire system.

What I Would Add Next

The next phase is controlled write operations.

I would add them in this order:

reload_nginx
restart_service
restart_container
create_database_backup
renew_ssl

But only after adding:

Approval handling
Risk levels
Post-action health checks
Better audit records
More security tests
Command timeout coverage
Backup verification

For deployment automation, I would be even more careful.

A deployment tool should not be:

git pull && docker compose up

It should be closer to a transactional workflow: validate service and version, acquire a deployment lock, record the current version, build an immutable artifact, run tests, create a backup if needed, start the new version, run readiness checks, switch traffic, monitor, roll back on failure, and release the lock.

That is a separate project.

Final Thoughts

The main lesson from this project is simple:

AI-assisted infrastructure should be designed like any other privileged system.

Do not rely on prompting for safety.

Do not give the model a shell and hope it behaves.

Do not expose broad sudo access.

Instead:

Constrain the interface
Validate inputs
Use allowlists
Pin host keys
Use dedicated users
Keep scripts root-owned
Sanitise output
Write audit logs
Start read-only
Add write operations slowly

The AI can still be useful.

It can summarise logs. It can spot unhealthy services. It can check SSL expiry. It can explain operational state.

But it does all of that inside boundaries that engineers control.

That is the model I trust more.

Not AI as root.

AI as an assistant with a well-designed operations API.

Deploying a Multi-Module Spring Boot App to Render with PostgreSQL, Redis, Docker, and Flyway

Ojo Ilesanmi — Tue, 23 Jun 2026 09:57:35 +0000

Deploying a Spring Boot backend should be simple in theory. Build the JAR, set the environment variables, connect the database, and ship it.

In practice, my deployment exposed several assumptions that worked locally but failed immediately in the cloud.

I recently deployed a modular Spring Boot application to Render using Docker, Render Blueprint, PostgreSQL, Redis, Flyway migrations, Spring profiles, Hibernate/JPA, and environment variables.

The application worked locally with MySQL and Redis, but deployment exposed several production-specific issues that were easy to miss in local development. This article documents the problems, why they happened, and how I fixed them properly.

Who This Article Is For

This article is useful if you are deploying a Spring Boot application to Render and your local setup uses MySQL, Redis, Flyway, Docker, or a multi-module Maven structure.

It is especially relevant if you are moving from a local MySQL setup to PostgreSQL in the cloud.

The Stack

The backend was a Java 17 Spring Boot application with multiple Maven modules:

alagbafo/
├── api-contracts
├── core
├── users
├── orders
├── payments
├── wallet
├── notifications
├── admin
├── subscriptions
└── app

The app module was the actual Spring Boot entry point.

Locally, the project used MySQL and Redis:

spring.datasource.url=jdbc:mysql://localhost:3306/alagbafo
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.data.redis.host=localhost
spring.data.redis.port=6379

For Render, the target setup was:

Spring Boot app
PostgreSQL database
Redis-compatible Key Value store
Docker deployment
Flyway migrations

Render Blueprint was the best fit because it allowed the infrastructure to be described in a render.yaml file.

Step 1: Dockerfile for a Multi-Module Spring Boot App

Because the project was a multi-module Maven application, the Dockerfile had to copy all module pom.xml files before copying the source code.

This improves Docker layer caching because dependencies can be downloaded before the full source code is copied.

# Stage 1: Build
FROM maven:3.9-eclipse-temurin-17 AS build

WORKDIR /app

COPY pom.xml .
COPY api-contracts/pom.xml api-contracts/
COPY core/pom.xml core/
COPY users/pom.xml users/
COPY orders/pom.xml orders/
COPY payments/pom.xml payments/
COPY wallet/pom.xml wallet/
COPY delivery/pom.xml delivery/
COPY notifications/pom.xml notifications/
COPY admin/pom.xml admin/
COPY support/pom.xml support/
COPY packages/pom.xml packages/
COPY subscriptions/pom.xml subscriptions/
COPY app/pom.xml app/

RUN mvn dependency:go-offline -B

COPY . .
RUN mvn clean package -DskipTests -B

# Stage 2: Run
FROM eclipse-temurin:17-jre-jammy

WORKDIR /app

COPY --from=build /app/app/target/*.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

This works well for Render because Render can build directly from the Dockerfile.

Step 2: The Render Blueprint

The deployment needed three resources:

A web service
A PostgreSQL database
A Redis service

The corrected render.yaml looked like this:

services:
  - type: web
    name: alagbafo
    runtime: docker
    dockerfilePath: ./Dockerfile
    plan: free
    envVars:
      - key: SPRING_PROFILES_ACTIVE
        value: render
      - key: JAVA_OPTS
        value: "-Xms256m -Xmx512m"
      - key: DATABASE_URL
        fromDatabase:
          name: alagbafo-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          type: redis
          name: alagbafo-redis
          property: connectionString
      - key: JWT_SECRET
        generateValue: true
      - key: APP_BASE_URL
        value: "https://alagbafo.onrender.com"
      - key: PAYSTACK_SECRET_KEY
        sync: false
      - key: PAYSTACK_PUBLIC_KEY
        sync: false
      - key: PAYSTACK_WEBHOOK_SECRET
        sync: false

  - type: redis
    name: alagbafo-redis
    plan: free
    ipAllowList: []

databases:
  - name: alagbafo-db
    plan: free
    databaseName: alagbafo
    ipAllowList: []

One important lesson: Redis does not belong under databases.

PostgreSQL goes under databases, while Redis goes under services with type: redis.

If Redis is declared incorrectly, Render will not inject REDIS_URL, and Spring Boot will fail at startup.

Step 3: Creating a Render-Specific Spring Profile

The first deployment failed with this:

Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure

That meant the application was still using the default MySQL configuration.

The cause was simple: the Render Spring profile was not active.

The fix was to create a Render-specific profile:

# application-render.properties
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
spring.flyway.locations=classpath:db/migration-pg
server.port=${PORT:8080}

Then I made sure Render set this environment variable:

SPRING_PROFILES_ACTIVE=render

Without this, Spring Boot keeps loading application.properties, which in my case pointed to MySQL.

Problem 1: Redis URL Was Empty

The next failure was:

The URL '' is not valid for configuring Spring Data Redis.
The scheme 'null' is not supported.
Use the scheme 'redis://' for insecure or 'rediss://' for secure Redis standalone configuration.

This happened because the Redis service was declared incorrectly in render.yaml.

I initially put Redis under databases, which was wrong.

The corrected Redis service definition was:

services:
  - type: redis
    name: alagbafo-redis
    plan: free
    ipAllowList: []

Then the web service can reference it:

- key: REDIS_URL
  fromService:
    type: redis
    name: alagbafo-redis
    property: connectionString

In Spring Boot, the Render profile uses:

spring.data.redis.url=${REDIS_URL}

Avoid using an empty fallback like this:

spring.data.redis.url=${REDIS_URL:}

That makes debugging harder because Spring receives an empty string and fails with a confusing URL error.

Problem 2: Render PostgreSQL URL Is Not a JDBC URL

Render provides PostgreSQL URLs like this:

postgresql://user:password@host/database

The PostgreSQL JDBC driver expects something like this:

jdbc:postgresql://host:5432/database

At first, I tried this:

spring.datasource.url=jdbc:${DATABASE_URL}

That produced a URL like this:

jdbc:postgresql://user:password@host/database

It looked close, but it still failed:

Driver org.postgresql.Driver claims to not accept jdbcUrl

The issue was that the JDBC URL should not include credentials in that URI format.

Spring/Hikari works better with this structure:

jdbc:postgresql://host:5432/database
username=user
password=password

So I created a Render-only datasource config:

package com.alagbafo.core.config;

import com.zaxxer.hikari.HikariDataSource;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

import javax.sql.DataSource;
import java.net.URI;

@Configuration
@Profile("render")
@ConditionalOnProperty(name = "DATABASE_URL")
public class RenderDataSourceConfig {

    @Bean
    public DataSource dataSource(@Value("${DATABASE_URL}") String databaseUrl) {
        URI uri = URI.create(databaseUrl);

        String[] userInfo = uri.getUserInfo().split(":", 2);
        String username = userInfo[0];
        String password = userInfo.length > 1 ? userInfo[1] : "";

        int port = uri.getPort() == -1 ? 5432 : uri.getPort();
        String jdbcUrl = "jdbc:postgresql://" + uri.getHost() + ":" + port + uri.getPath();

        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl(jdbcUrl);
        dataSource.setUsername(username);
        dataSource.setPassword(password);
        dataSource.setDriverClassName("org.postgresql.Driver");
        return dataSource;
    }
}

This solved the datasource issue cleanly.

Step 4: Adding PostgreSQL Dependencies

The project originally only had MySQL:

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

For Render, I added PostgreSQL:

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <scope>runtime</scope>
</dependency>

Since Flyway was being used, I also added PostgreSQL database support:

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-database-postgresql</artifactId>
</dependency>

Problem 3: MySQL Flyway Migrations Do Not Run on PostgreSQL

The local migrations used MySQL syntax:

CREATE TABLE users_user (
    id BIGINT NOT NULL AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL,
    created_at DATETIME(6) NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_users_user_email (email),
    KEY idx_user_created (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

PostgreSQL does not understand MySQL-specific syntax like:

AUTO_INCREMENT
DATETIME(6)
UNIQUE KEY
KEY
ENGINE=InnoDB
DEFAULT CHARSET
COLLATE=utf8mb4_unicode_ci
ON DUPLICATE KEY UPDATE

So I created a separate migration folder for PostgreSQL:

core/src/main/resources/db/migration-pg

Then the Render profile pointed Flyway there:

spring.flyway.locations=classpath:db/migration-pg

A PostgreSQL-compatible version looks like this:

CREATE TABLE users_user (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    user_id VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP(6) NOT NULL,
    CONSTRAINT uk_users_user_user_id UNIQUE (user_id),
    CONSTRAINT uk_users_user_email UNIQUE (email)
);

CREATE INDEX idx_user_created ON users_user (created_at);

For MySQL upserts like this:

ON DUPLICATE KEY UPDATE

PostgreSQL uses:

ON CONFLICT (code) DO UPDATE SET
    name = EXCLUDED.name,
    description = EXCLUDED.description;

Problem 4: JSON vs JSONB vs Hibernate Validation

After database connectivity was solved, Hibernate schema validation failed:

Schema-validation: wrong column type encountered in column [new_value]
in table [admin_audit_log];
found [jsonb (Types#OTHER)], but expecting [json (Types#VARCHAR)]

The entity had:

@Column(name = "new_value", columnDefinition = "JSON")
private String newValue;

But the PostgreSQL migration had created:

new_value JSONB

PostgreSQL supports both json and jsonb, but Hibernate was validating strictly against the entity definition.

I fixed the PostgreSQL migration:

old_value JSON,
new_value JSON

Because the old migration had already run on Render, I added a corrective migration:

ALTER TABLE admin_audit_log
    ALTER COLUMN old_value TYPE JSON USING old_value::JSON,
    ALTER COLUMN new_value TYPE JSON USING new_value::JSON;

ALTER TABLE notifications
    ALTER COLUMN template_variables TYPE JSON USING template_variables::JSON;

Problem 5: Hibernate Validation Can Be Too Strict for Deployment

In local development, this was useful:

spring.jpa.hibernate.ddl-auto=validate

In a production-style environment with Flyway, I changed it to:

spring.jpa.hibernate.ddl-auto=none

This is the better setup when Flyway owns schema management.

The final Render profile became:

# application-render.properties
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
spring.jpa.hibernate.ddl-auto=none
spring.jpa.open-in-view=false

spring.flyway.locations=classpath:db/migration-pg
spring.flyway.validate-on-migrate=false

spring.data.redis.url=${REDIS_URL}
server.port=${PORT:8080}

Flyway handles migrations. Hibernate runs the app. They do not fight each other.

Environment Variables on Render

These were required:

SPRING_PROFILES_ACTIVE=render
DATABASE_URL=auto-injected by Render PostgreSQL
REDIS_URL=auto-injected by Render Redis
JWT_SECRET=secure-generated-secret

Paystack could be added later, but the app expected placeholders during setup:

PAYSTACK_SECRET_KEY=sk_test_dummy
PAYSTACK_PUBLIC_KEY=pk_test_dummy
PAYSTACK_WEBHOOK_SECRET=dummy

For a secure JWT secret, generate one locally:

openssl rand -base64 48

Final Checklist

If you are deploying a Spring Boot app to Render with Blueprint, PostgreSQL, Redis, Docker, and Flyway, check these:

Use New Blueprint, not just New Web Service.
Put PostgreSQL under databases.
Put Redis under services with type: redis.
Set SPRING_PROFILES_ACTIVE=render.
Do not use MySQL migrations for PostgreSQL.
Use separate Flyway folders for database-specific migrations.
Convert Render postgresql://... URL to JDBC format.
Let Flyway manage schema.
Set spring.jpa.hibernate.ddl-auto=none in deployment.
Add dummy values for optional third-party secrets if needed.
Keep real secrets in Render environment variables, not code.

Final Thoughts

The frustrating part was that every fix revealed the next layer.

First, MySQL was still being used. Then Redis was not injected. Then the PostgreSQL URL format was wrong. Then Flyway migrations needed PostgreSQL syntax. Then Hibernate schema validation complained about JSON types.

But each failure made the deployment more production-ready.

The key lesson is this: local development hides infrastructure assumptions, while cloud deployment exposes them.

Once the app had a proper Render profile, correct Blueprint config, PostgreSQL-specific Flyway migrations, and a datasource parser for Render’s database URL, the deployment became predictable.

That was the real win.

Building DTOForge: Java DTO Generator for Spring Boot Applications

Ojo Ilesanmi — Wed, 10 Jun 2026 10:50:40 +0000

If you have worked on Java or Spring Boot applications, you have probably spent time creating DTOs, request classes, response classes, and mapping logic over and over again.

At first, it looks simple. But as the codebase grows, DTO management can quickly become repetitive, time-consuming, and easy to get wrong. You may have multiple entities, different API response formats, validation requirements, and small changes that need to be repeated across several files.

That was the problem that led me to build DTOForge.

DTOForge is an open-source Java tool designed to simplify DTO generation for backend applications. The goal is straightforward: help Java developers reduce boilerplate code, generate cleaner DTO structures, and spend more time focusing on actual business logic.

Why DTO Generation Matters in Java Applications

In many Spring Boot applications, DTOs are used to separate internal data models from what the API exposes. This is a good practice because it improves security, maintainability, and flexibility.

However, manually creating DTOs can become stressful when:

The application has many entities
Request and response objects keep changing
Developers need different DTOs for different use cases
Mapping logic becomes repetitive
The team wants to maintain clean API contracts

Tools like Lombok help reduce boilerplate inside classes, but they do not fully solve the problem of creating and organizing DTOs across a growing Java backend project.

What DTOForge Does

DTOForge helps generate DTO classes from existing Java models. Instead of manually creating DTO files every time, developers can use DTOForge to speed up the process and keep their codebase cleaner.

The project focuses on:

Reducing repetitive DTO creation
Improving developer productivity
Supporting cleaner backend architecture
Making Java API development faster
Creating a foundation for future code generation workflows

How DTOForge Was Designed

I built DTOForge with simplicity and extensibility in mind.

The tool is designed to be lightweight, so it can fit into existing Java development workflows without forcing developers to change how they already build applications.

The structure also makes it easier to add more features later, such as:

Custom DTO templates
Maven plugin support
Gradle plugin support
CLI-based DTO generation
Support for different DTO patterns
More flexible field selection

This makes DTOForge more than just a small utility. It is a foundation for a broader developer tooling system around Java backend productivity.

Why I Built It

I enjoy building tools that make engineering work simpler.

In backend development, small repetitive tasks can slow teams down over time. DTO creation is one of those tasks. It may not look like a major issue at first, but in large systems, repetition affects speed, consistency, and maintainability.

DTOForge is my attempt to solve that problem in a practical way for Java developers.

It reflects a simple engineering principle: developers should spend less time writing repetitive code and more time designing reliable systems.

What I Learned from Building DTOForge

Building DTOForge helped me think more deeply about developer tooling, code generation, and clean architecture.

It also strengthened my understanding of how small tools can improve productivity in real-world engineering teams. A good developer tool does not need to be complex. It just needs to solve a clear problem well.

DTOForge is still evolving, and I plan to keep improving it with better documentation, more generation options, and smoother integration into Java workflows.

Conclusion

DTOForge is an open-source Java DTO generator built to help backend developers reduce boilerplate and streamline DTO creation in Spring Boot applications.

The project is part of my broader interest in building open-source tools that improve developer productivity and simplify backend development.

GitHub Repository: https://github.com/ojoilesanmi/dtoforge