Skysculptor: Separating MCP Servers and Stabilizing Deployment

Context

Skysculptor consumes two MCP servers (sky and weather). Initially, everything ran in the same pod as the app — simple but not ideal for production.

The Problem

Each Skysculptor replica bundled two MCP servers. This multiplied resource consumption, complicated restarts, and made scaling hard to control.

Solution(s) Attempted

• Keep everything in the same pod (sidecars): simple but expensive and tightly coupled.
• Separate into dedicated services with distinct K8s Deployments and internal Services.

Result

We extracted mcp-sky and mcp-weather into their own images and Deployments, exposed via internal Services. Skysculptor now points to these internal endpoints and no longer depends on a bundled "MCP package" in its pod.

Concretely:

• Two dedicated Dockerfiles for mcp-sky and mcp-weather, built as standard Node services.
• Two Deployments + Services (ports 3003 and 3002) with probes on /health and internal ClusterIP.
• Skysculptor consumes MCP via MCP_SKY_URL and MCP_WEATHER_URL.
• CI/CD pushes immutable tags (github.sha) and applies manifests with a IMAGE_TAG placeholder.
• Added a k8s-apply.sh script to apply the SHA tag without editing manifests.
• HPA at 70% CPU on Skysculptor and both MCPs.

Diagram

Resources

Simple choices to start:

• Skysculptor: requests 256Mi / 200m, limits 1Gi / 1000m.
• MCP sky + weather: requests 128Mi / 50m, limits 256Mi / 250m.
• HPA at 70% CPU, min 1, max 3.

These values are intentionally conservative. The goal is to limit waste while load is low, while leaving headroom.

Verification

Quick checklist after deployment:

• Health checks: /health on mcp-sky and mcp-weather.
• Skysculptor responds on the ingress.
• HPA active: kubectl get hpa -n brunodogbase
• Metrics OK: kubectl top pods -n brunodogbase