I've Got the Polyglot Blues: TypeScript Scales in Your Mind, Not Your Infrastructure

Who this is for: teams who standardized on TypeScript for good reasons and keep paying for it in the wrong places.

TypeScript is a wonderful way to think, and a fine way to build a product API. It is not the right tool for a high-throughput ingestion service, a Python ML pipeline, or an agent that wants the whole PyData universe. But "rewrite it in TS because that's what our platform deploys" is how teams ship worse systems to avoid running a second platform. On kilter you don't run a second platform — every language is the same deploy.

The recipe

1. Split by job, not by language politics. TS for the product API, Python for the agent/worker, Go for the throughput-critical service.
2. One project, many apps. kilter init, then declare each service in kilter.yaml with its own language and runtime — no second repo, no second pipeline.
3. Share state through real infrastructure. postgres for data, temporal for cross-language durable workflows, kafka if you need a bus — not a monolith pretending to be a message queue.
4. Scale each independently. Free-tier apps scale-to-zero via KEDA when idle; production-lite services stay warm. The Python worker and the Go service right-size themselves.
5. Run the whole polyglot stack locally. kilter up — one command boots every service, whatever it's written in.
6. Ship all of it at once. kilter deploy — every service live in production, Org Only, through one pipeline regardless of language.
7. Expose selectively. Hit Promote on the services that need external access; the internal ones stay Org Only.

Pick the language that fits the problem, not the one that fits your deploy. When "all of them" is the cheap answer, the polyglot blues go away.