The Stack at a Glance

No EC2 instances. No always-on compute. Nothing to patch or resize.

Infrastructure as Code with AWS CDK

Everything lives in a single CDK stack (CdkStack) written in TypeScript. The whole deployment is reproducible from a clean AWS account with one command:

cdk deploy --all --require-approval never

The stack is parameterized via environment variables, which is what allows the same code to power both production and a staging environment:

const domainName = process.env.DOMAIN_NAME || 'aldolushkja.it';
const certificateArn = process.env.CERTIFICATE_ARN;

new CdkStack(app, 'RootPortfolioStack', {
  env: { account: CDK_DEFAULT_ACCOUNT, region: CDK_DEFAULT_REGION },
  domainName,
  certificateArn,
});

S3 — Static File Hosting

Two S3 buckets handle the two domain variants:

• aldolushkja.it — root domain
• www.aldolushkja.it — www subdomain

Both serve index.html as the index and error document (which is what makes SPA routing work without a server). Bucket versioning is enabled so rollbacks are trivial if a broken deploy goes out.

const rootBucket = new s3.Bucket(this, 'RootBucket', {
  bucketName: props.domainName,
  websiteIndexDocument: 'index.html',
  websiteErrorDocument: 'index.html',
  versioned: true,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
  autoDeleteObjects: true,
});

Cost: a personal portfolio gets maybe a few thousand requests per month and stores well under 1 MB of HTML/CSS/JS. At S3 pricing this is effectively free — we're talking fractions of a cent.

CloudFront — CDN, HTTPS, and Caching

CloudFront sits in front of S3 and handles three things:

1. HTTPS termination — the origin is plain S3, CloudFront adds TLS at the edge.
2. Global caching — assets are cached at 400+ edge locations, so visitors anywhere in the world get sub-50ms loads.
3. Custom domain aliases — both aldolushkja.it and www.aldolushkja.it resolve to the same distribution.

const distribution = new cloudfront.CloudFrontWebDistribution(this, 'SiteDistribution', {
  originConfigs: [{
    s3OriginSource: { s3BucketSource: rootBucket },
    behaviors: [{ isDefaultBehavior: true }],
  }],
  viewerCertificate: cloudfront.ViewerCertificate.fromAcmCertificate(certificate, {
    aliases: [props.domainName, `www.${props.domainName}`],
    securityPolicy: cloudfront.SecurityPolicyProtocol.TLS_V1_2_2021,
    sslMethod: cloudfront.SSLMethod.SNI,
  }),
});

Cost: CloudFront's free tier covers 1 TB of data transfer and 10 million HTTP requests per month. A personal portfolio will never get close to that.

ACM — Free SSL Certificates

ACM certificates are completely free. The only constraint is that certificates used with CloudFront must be provisioned in us-east-1, regardless of where the rest of your infrastructure lives.

The stack handles this in two ways:

• If you pass in a pre-existing certificate ARN via env var → it uses that (useful if you already have a wildcard cert).
• Otherwise → it creates a DnsValidatedCertificate that auto-validates via Route 53 DNS records.

if (props.certificateArn) {
  certificate = acm.Certificate.fromCertificateArn(this, 'Certificate', props.certificateArn);
} else {
  certificate = new acm.DnsValidatedCertificate(this, 'SiteCertificate', {
    domainName: props.domainName,
    subjectAlternativeNames: [`www.${props.domainName}`],
    hostedZone: zone,
    region: 'us-east-1',
  });
}

Route 53 — DNS Management

Route 53 manages the hosted zone for aldolushkja.it. Two A records (alias records) point both the root and www domains to the CloudFront distribution:

new route53.ARecord(this, 'SiteAliasRecord', {
  recordName: props.domainName,
  target: route53.RecordTarget.fromAlias(new targets.CloudFrontTarget(distribution)),
  zone,
});

new route53.ARecord(this, 'WWWSiteAliasRecord', {
  recordName: `www.${props.domainName}`,
  target: route53.RecordTarget.fromAlias(new targets.CloudFrontTarget(distribution)),
  zone,
});

Alias records to CloudFront are free — AWS doesn't charge for queries to alias records that resolve to AWS resources. The only cost is the hosted zone itself: $0.50/month.

The Build Pipeline — Docker in CDK

The frontend build happens inside CDK's bundling step using a Docker container. This means the CI runner doesn't need Node.js pre-installed — CDK pulls a node:22 image and builds inside it:

const frontendAsset = s3Deploy.Source.asset(frontendPath, {
  bundling: {
    image: cdk.DockerImage.fromRegistry('node:22'),
    environment: {
      COMMIT_SHA: commitSha, // injected into index.html at build time
    },
    command: [
      'bash', '-c',
      'npm install && npm run build:css && npm run build && cp -r dist/* /asset-output',
    ],
    user: 'root',
  },
});

After deployment, CloudFront's cache is automatically invalidated for /* — so visitors always get the latest version without stale edge caches:

const rootDeployment = new s3Deploy.BucketDeployment(this, 'RootDeployment', {
  destinationBucket: rootBucket,
  sources: [frontendAsset],
  distribution: distribution,
  distributionPaths: ['/*'], // automatic cache bust on every deploy
});

Two Environments, One Codebase

I maintain two environments: production (aldolushkja.it) and staging (dev.aldolushkja.it). Both are driven by the same CDK stack — the only difference is the DOMAIN_NAME environment variable.

cdk-deploy.yml triggers on push to master — no DOMAIN_NAME set, so it defaults to aldolushkja.it.

cdk-deploy-dev.yml triggers on push to dev:

env:
  DOMAIN_NAME: dev.aldolushkja.it

This means I can test infrastructure changes on the dev subdomain before they hit production — without any extra tooling or duplication.

What's the Actual Monthly Bill?

For a personal portfolio with moderate traffic:

That's it. The only real cost is the Route 53 hosted zone. Everything else fits comfortably within free tiers or rounds to zero at personal-site traffic levels.

What I'd Add Next

The repo already has a BackendStack defined (but not deployed) for a Lambda + API Gateway contact form. When I activate it, Lambda's free tier (1M requests/month) means it'll still cost essentially nothing.

Takeaways

• Static sites on S3 + CloudFront are the most cost-efficient way to host anything that doesn't need a server. The combination gives you global CDN, HTTPS, and high availability for pocket change.
• AWS CDK makes this reproducible and testable. The entire infrastructure is TypeScript, sits in the same repo as the frontend, and has unit tests.
• Parameterizing the stack for multiple environments costs nothing extra — it's just the same S3/CloudFront/Route53 setup pointed at a different domain.

That's the gap I wanted to close.

What is MCP and why does it matter?

Model Context Protocol (MCP) is an open standard that lets AI assistants call external tools directly. Instead of you describing your data to the AI, the AI fetches it itself. It's the difference between "I have 14 open bugs, here's a summary..." and just asking "What are my open bugs?" and getting the answer.

If your team uses Targetprocess, you interact with it dozens of times a day — checking user stories, creating tasks, linking blockers, updating statuses. All of that is now something your AI assistant can do for you.

The result: zdtp-mcp

zdtp-mcp is an MCP server that exposes 52 tools across 15 Targetprocess domains:

One Docker command to set it up:

# Claude Code
claude mcp add zdtp -- docker run -i --rm \
  -e TP_URL="https://youraccount.tpondemand.com" \
  -e TP_TOKEN="your_token" \
  ghcr.io/aldo-lushkja/zdtp-mcp:latest

# Gemini CLI
gemini mcp add zdtp docker run -i --rm \
  -e TP_URL="https://youraccount.tpondemand.com" \
  -e TP_TOKEN="your_token" \
  ghcr.io/aldo-lushkja/zdtp-mcp:latest

Then you can just ask:

"Find all open bugs assigned to me in Project Alpha"

"Link US-123 as a blocker of US-456"

"Create a test case with steps for the payment flow"

"Show me all releases due this month"

Why Java 21 and zero dependencies?

Most MCP servers I've seen are built with Python or TypeScript, often with a framework doing heavy lifting. I chose Java 21 with a deliberate zero-framework policy: no Spring, no Quarkus, no HTTP framework of any kind.

The reasons:

Startup time. MCP servers over stdio are spawned on demand — every time the AI client needs them. A Spring Boot service takes a few seconds to start. A plain Java process with a shadow JAR is up in under 100ms.

Size. The final fat JAR is small. No framework means no classpath scanning, no annotation processing, no auto-configuration. The Docker image stays lean.

Predictability. When something breaks, you read the code — not a framework's internals. For a small, focused tool this matters a lot.

The only dependencies are Jackson (JSON) and Commonmark (Markdown-to-HTML for description fields). Everything else — HTTP client, stdio loop, JSON-RPC parsing — is standard Java 21.

Architecture: BCE

The project follows the Boundary-Control-Entity (BCE) pattern:

McpServer (stdio JSON-RPC loop)
    └── *McpTools        ← Boundary: registers tools, formats output
        └── *Service     ← Control: business logic, calls QueryEngine
            └── QueryEngine → Targetprocess REST API

Each Targetprocess domain (UserStory, Bug, Task, etc.) is a vertical slice with its own boundary, control, and entity classes. Adding a new domain is a matter of copying the pattern — no framework wiring, no configuration files.

The McpServer class itself is ~140 lines. It reads JSON-RPC from stdin, dispatches to registered tool handlers, and writes responses to stdout. That's the entire transport layer.

Multi-platform Docker image

The published image targets both linux/amd64 and linux/arm64, so it runs natively on Apple Silicon without Rosetta emulation:

ghcr.io/aldo-lushkja/zdtp-mcp:latest   # stable
ghcr.io/aldo-lushkja/zdtp-mcp:develop  # latest dev build

The CI/CD pipeline is a full Git Flow setup on GitHub Actions: feature branches merge into develop, release branches cut from develop and merge into main, Docker images are tagged automatically per branch.

What's next

The server currently supports stdio transport only. HTTP/SSE transport would allow deploying it as a shared team service — one running instance, multiple AI clients pointing at it. That's the next milestone.

If your team uses Targetprocess and AI assistants, give it a try. PRs and issues welcome.

As a software engineer who's spent years optimizing development workflows, I can confidently say that Docker and Docker Compose have revolutionized how we set up and manage local development environments. In this article, I'll share practical insights on using these tools to build robust infrastructure and accelerate your development process.

🤌🏻 Why Docker for Local Development?

Before diving into the how-to's, let's address a fundamental question: Why should you use Docker for local development? Here are the compelling reasons:

1. Consistency: The age-old "it works on my machine" problem becomes a thing of the past

2. Isolation: Each project runs in its own container, preventing dependency conflicts

3. Reproducibility: New team members can start contributing in minutes, not days

4. Scalability: Easily add new services as your application grows

⚙️Getting Started with Docker

To begin your Docker journey, you'll need to install Docker Desktop (for Windows/Mac) or Docker Engine (for Linux). Once installed, you can create your first Dockerfile:

# Use an official Node.js runtime as the base image
FROM node:18-alpine

# Set the working directory
WORKDIR /app

# Copy package files
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the application
COPY . .

# Expose port 3000
EXPOSE 3000

# Start the application
CMD ["npm", "start"]

🚄 Enter Docker Compose: Managing Multi-Container Applications

While Docker is great for single containers, real-world applications often require multiple services working together. This is where Docker Compose shines. Here's a practical example:

version: '3.8'
services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
    depends_on:
      - db
      - redis

  db:
    image: postgres:14-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=myapp
      - POSTGRES_PASSWORD=mypassword
      - POSTGRES_DB=myapp_development

  redis:
    image: redis:alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

📋Best Practices for Local Development

1. Use Volume Mounting

Instead of rebuilding containers for every code change, use volume mounting to reflect changes instantly:

volumes:
  - .:/app  # Mount current directory to /app in container
  - /app/node_modules  # Preserve container's node_modules

2. Environment Management

Create separate .env files for different environments:

# .env.development
DB_HOST=db
REDIS_URL=redis://redis:6379
NODE_ENV=development

3. Development-Specific Optimizations

For local development, consider these additions to your docker-compose.yml:

services:
  web:
    # ... other configurations ...
    command: npm run dev  # Use development server
    ports:
      - "9229:9229"  # Enable debugging

🌊 Common Development Workflows

Starting Your Development Environment

# Start all services
docker-compose up -d

# View logs
docker-compose logs -f web

# Stop all services
docker-compose down

Running Tests

# Run tests in the web service
docker-compose exec web npm test

# Run database migrations
docker-compose exec web npm run migrate

🛠️ Advanced Tips and Tricks

1. Docker Compose Override Files

Use docker-compose.override.yml for development-specific settings:

# docker-compose.override.yml
services:
  web:
    command: npm run dev
    volumes:
      - .:/app
    environment:
      - DEBUG=true

2. Multi-Stage Builds

Optimize your production builds while keeping development containers lean:

# Development stage
FROM node:18-alpine AS development
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

# Production stage
FROM node:18-alpine AS production
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=development /app/dist ./dist
CMD ["npm", "start"]

🔨 Common Pitfalls and Solutions

1. Container Performance Issues

   • Use .dockerignore to exclude unnecessary files

   • Implement proper volume mounting strategies

   • Consider using Docker Desktop's resource limits

2. Database Persistence

   • Always use named volumes for databases

   • Implement proper backup strategies

   • Use volume mounting for development data

3. Network Issues

   • Use service names as hostnames

   • Properly manage port mappings

   • Understand Docker's networking models

👋🏻 Conclusion

Docker and Docker Compose are powerful tools that can significantly improve your local development workflow. By following these practices and understanding the underlying concepts, you can create a development environment that's both efficient and enjoyable to work with.

Remember: The goal is to spend less time fighting with environment setup and more time writing great code. Docker helps achieve exactly that.

📚 Additional Resources

• Official Docker Documentation

• Docker Compose Documentation

• Docker Best Practices

In the dynamic landscape of web development, the need for efficient, scalable, and asynchronous communication has become paramount. Netty, a robust and high-performance networking framework, coupled with a reactive HTTP client, offers a powerful solution to meet these demands. In this article, we will explore the fundamentals of Netty and delve into the intricacies of sending requests using a reactive HTTP client.

💡 Understanding Netty

Netty, an open-source framework, excels in building high-performance and scalable network applications. Its asynchronous event-driven architecture is well-suited for handling a large number of connections simultaneously, making it a popular choice for building servers and clients in various domains.

⭐ Key Features of Netty

1. Event-Driven Model: Netty utilizes an event-driven programming model, allowing developers to handle I/O operations asynchronously. This helps in achieving high concurrency and responsiveness in applications.

2. Channel Abstraction: Netty's channel abstraction simplifies network communication by providing a consistent interface for various transport types, such as sockets or Datagram channels.

3. Thread Pools: Netty efficiently manages threads through its customizable thread pools, optimizing resource utilization and ensuring smooth operation in high-throughput scenarios.

🚀 Reactive HTTP Client

To enhance the capabilities of Netty, developers often integrate a reactive HTTP client. Reactive programming is an approach that focuses on handling asynchronous data streams and the propagation of change. When applied to HTTP communication, it provides a non-blocking and event-driven paradigm, aligning well with Netty's principles.

Advantages of Reactive HTTP Client with Netty

1. Asynchronous Communication: Reactive HTTP clients, such as WebClient in the Spring WebFlux framework or Project Reactor's Mono and Flux, allow developers to perform HTTP requests asynchronously. This is particularly beneficial in scenarios where responsiveness and scalability are critical.

2. Streamlined Error Handling: Reactive programming facilitates concise error handling through features like reactive streams and onError. This makes it easier to manage errors and respond appropriately in asynchronous environments.

3. Backpressure Support: Reactive HTTP clients often come with built-in support for backpressure, allowing applications to manage the flow of data efficiently. This is crucial for preventing overload in scenarios where the producer is faster than the consumer.

💻 Sample Code Snippet - Sending Request with Netty and Reactive HTTP Client

import reactor.core.publisher.Mono;
import org.springframework.web.reactive.function.client.WebClient;

public class ReactiveHttpClientExample {
    private final WebClient webClient;

    public ReactiveHttpClientExample() {
        this.webClient = WebClient.builder()
                .baseUrl("http://example.com")
                .build();
    }

    public Mono<String> sendRequest() {
        return webClient.get()
                .uri("/api/data")
                .retrieve()
                .bodyToMono(String.class)
                .doOnError(error -> System.err.println("Error occurred: " + error.getMessage()));
    }
}

👋🏻 Conclusion

In the ever-evolving landscape of web development, Netty and reactive HTTP clients provide a robust foundation for building high-performance, asynchronous, and scalable applications. Developers can leverage the strengths of both technologies to create responsive systems capable of handling a large number of concurrent connections. Asynchronous communication, streamlined error handling, and backpressure support make the combination of Netty and reactive HTTP clients a compelling choice for modern, data-intensive applications.