Skew Protection is available now in ICC as an experimental feature.
If your team wants to try it in a real enterprise setup, let me know; my DMs are open.
Full deep-dive blog post: blog.platformatic.dev/skew-protect...
The deployment lifecycle is a clean state machine.
ICC monitors traffic on draining versions. When there's zero traffic (or the grace period elapses), it removes routing rules, scales to zero, and optionally deletes the old Deployment.
How it works:
- Each app version runs as a separate, immutable K8s Deployment
- ICC detects new versions via label-based discovery
- A __plt_dpl cookie pins users to their deployment version
- Old versions drain gracefully, then get cleaned up automatically
Our solution: ICC pins each user session to the version they started with.
User starts on version N? All their requests go to version N, even after you deploy version N+1.
We use the Kubernetes Gateway API for version-aware routing, with ICC as the control plane.
This is a distributed systems problem that slows teams down.
Fear of breaking changes leads to larger, less-frequent deployments that carry MORE risk.
In a world where AI lets you write code faster, the bottleneck lies in the gap between code and production.
The problem: version skew.
When you deploy a new version, users still on the old frontend send requests to the new backend. APIs change, shared TypeScript types break, React Server Components hydration fails.
The result? Broken UI, data corruption, and support tickets piling up.
We just shipped something big: Skew Protection for your Kubernetes apps, built right into the @platformatic Intelligent Command Center (ICC).
Think @Vercel-style deployment safety, but running in your own K8s cluster. No migration needed.
Here's why it matters. 🧵
Skew Protection is available now in ICC as an experimental feature.
If your team wants to try it in a real enterprise setup, let me know; my DMs are open.
Full deep-dive blog post: blog.platformatic.dev/skew-protect...
The deployment lifecycle is a clean state machine.
ICC monitors traffic on draining versions. When there's zero traffic (or the grace period elapses), it removes routing rules, scales to zero, and optionally deletes the old Deployment.
How it works:
- Each app version runs as a separate, immutable K8s Deployment
- ICC detects new versions via label-based discovery
- A __plt_dpl cookie pins users to their deployment version
- Old versions drain gracefully, then get cleaned up automatically
Our solution: ICC pins each user session to the version they started with.
User starts on version N? All their requests go to version N, even after you deploy version N+1.
We use the Kubernetes Gateway API for version-aware routing, with ICC as the control plane.
This is a distributed systems problem that slows teams down.
Fear of breaking changes leads to larger, less-frequent deployments that carry MORE risk.
In a world where AI lets you write code faster, the bottleneck lies in the gap between code and production.
The problem: version skew.
When you deploy a new version, users still on the old frontend send requests to the new backend. APIs change, shared TypeScript types break, React Server Components hydration fails.
The result? Broken UI, data corruption, and support tickets piling up.
We just shipped something big: Skew Protection for your Kubernetes apps, built right into the Platformatic Intelligent Command Center (ICC).
Think Vercel-style deployment safety, but running in your own K8s cluster. No migration needed.
Here's why it matters. 🧵
Read the full blog post at blog.platformatic.dev/auditable-ai...
Run it locally!
🔗 github.com/platformatic/ai-gateway-auditable
Why this matters: graceful degradation vs data loss.
Temporary failures = brief audit lag.
Lost audit data = regulatory risk, fines.
We trade insight delays for certainty no evidence is lost.
Streaming preserved: proxy pipes SSE chunks real-time, buffers, then emits audit record with streamed: true.
Users get low-latency streaming. Operators get complete records. Win-win.
The audit pipeline:
1. Proxy enqueues payload
2. audit-worker writes JSONL batches (100 records or 5s)
3. Upload to S3 with SigV4
4. Delete local only after success
Hour-partitioned keys work great with Athena.
Why filesystem-based storage? No Redis needed = simpler local dev. Still crash-tolerant: queue survives process restarts.
⚠️ Trade-off: moving audit to main response cycle introduces latency.
Architecture at a glance:
• proxy — low-latency request/response
• audit-worker — durable queue consumption + batch shipping to S3
Keeps user-facing traffic fast while audit pipeline catches up safely.
That's why we built ai-gateway-auditable.
OpenAI-compatible gateway with @Platformatic Watt:
✅ Provider routing with fallback
✅ Durable audit logging to S3
✅ Production-ready
🔗 github.com/platformatic/ai-gateway-auditable
The problem: direct integrations = audit gaps. Finance needs clean attribution. Security needs auditable traces. Our early adopter saw up to 15% of request logs missed during peak volume, latency spiked 2x when providers slowed.
Every engineering team hitting scale with AI faces the same headache: what started as a simple provider integration becomes an operational nightmare. Usage tracking, cost containment, and audit trails slip out of reach fast.
🧵 Here's how we solved it.
The clanker can certainly do that quickly enough. Use node:sqlite.
Full story at blog.platformatic.dev/job-queue-re...
We've been testing this @platformatic, and it's been solid.
But we want YOUR edge cases. Try it, break it, open issues.
📦 npm install @platformatic/job-queue
🔗 github.com/platformatic...
TypeScript-native. Typed payloads and results.
Production reliability features:
⚡ Reaper detects stalled jobs and requeues them
⚡ Leader election so multiple Reaper instances run safely
⚡ Graceful shutdown waits for in-flight jobs
⚡ Failed jobs persist errors for inspection
Ship deploys without losing work.
Three storage backends for different stages:
👻 MemoryStorage - dev & testing
💾 FileStorage - simple single-node deploys
☁️ RedisStorage - production, horizontal scaling, leader election
Start local, go distributed. No code changes.
