Top 2 Recommendations

httpxy (Recommended)

• Stars: 277 | Open Issues: 9 | Last Updated: March 2026
• URL: https://github.com/unjs/httpxy
• Key Benefits:
  • Most active (unjs is a reputable org behind Nuxt/Nitro/Vite ecosystem)
  • Full-featured HTTP & WebSocket proxy
  • TypeScript with modern patterns
  • ESM-native (modern module system)
  • Minimal dependencies
  • Actively maintained (9 issues only)

http-proxy-3 (Direct Replacement)

• Stars: 92 | Open Issues: 13 | Last Updated: March 2026
• URL: https://github.com/sagemathinc/http-proxy-3
• Key Benefits:
  • Drop-in replacement (“Modern rewrite of node-proxy”)
  • API compatible with original http-proxy
  • TypeScript
  • Requires Node.js 18+
  • Fewer stars/maturity than httpxy

A couple of comments from my side:

1. Everyone should always secure their DDP as much as possible (rate limiting, encryption, and avoiding method abuse).
2. I’m still trying to fully grasp the use case for creating an MCP server for your app. Since your users can already use the app directly, why would they need an AI agent to do it for them? For something like creating a CS ticket, that can usually be handled within the app’s own logic.

Generally, an AI agent needs access to another server or app via an MCP server (or even a CLI, which is much more token-efficient) when that app belongs to a different ecosystem (like TrendRadar or MindsDb) or provides a necessary third-party service (like Context7).

Which specific AI agent or workflow is the target group for your MCP server?

In the world of agentic coding, integrating an app with Slack or a payment gateway (Stripe, PayPal, etc.) is often a relatively quick task for an AI agent. I handle my own automations using BullMQ, and it works perfectly for integrations with tools like PayPal, Buy Me a Coffee, and Chargebee.

Ultimately, I prefer to stay in full control of my DDP connections, or the absence of them for my airtight on-prem servers, to manage exactly what my methods do. I might place extra emphasis on this because my own SaaS handles sensitive DNA data. Ensuring that user data is 100% safe is my top priority; a single breach can be devastating for a company in that space.

Anyway, this is just my personal PoV based on my specific situation. I’m sure others see it differently, and you clearly have a different perspective. Please don’t take this as a personal attack or me trying to talk down your idea, it’s just not the right fit for my current stack.

What I really appreciate about your post is the “food for thought.” Exploring how AI agents can be helpful and pushing these boundaries is exactly what makes these discussions valuable. Thank you for taking the time to explain your thoughts so clearly.

Keep us posted!

dupontbertrand:

• uWebSockets: best raw performance, but single C++ maintainer (aand uWebSockets has had a somewhat unusual npm/distribution history deprecated uws, unpublished legacy versions, and periods where npm was explicitly discouraged by the maintainer, which makes it a riskier core dependency choice than ws)

As a uWebSockets user I havent any issue with it, but i agree the npm fight the mantainer have sucks a little bit.

uwebsockets come as a optin feature here but I agree with you when you say the dafault should be a native WebSocket implementation, my unique concern about replace the default sockJS is possibilty to create a major braking change.

As we can see both ws and uwebsockets repositories is being updated with a small frequency, uwebsockets have more issues then ws but not too much, it’s prettry stable.

Wormhole doesn’t introduce a new attack surface — it exposes the same server methods you already expose through DDP, just through a structured interface (MCP and optionally REST). If a Meteor method is insecure, it’s already insecure today. Wormhole just makes the interface more transparent.

In fact, I bet a lot of teams will find it pushes them toward better security practices, because:

• You can run it in opt-in mode and only expose explicitly approved methods, like maybe a knowledge-base search or a open support ticket.
• You can add schemas and validation so inputs are strictly defined. Not everyone does this with Meteor, and you’d be surprised how much code I’ve seen that doesn’t use check/match.
• You can add API key authentication and make sure only authorized users can hit your MCP.
• You can exclude patterns like admin.* or anything internal.

So the philosophy is basically: secure your methods properly once, and then they become reusable tools.

Where it becomes interesting is what that unlocks.

1. AI assistants operating your app

Instead of writing custom integrations, your app becomes a set of tools an AI assistant can use.

Example:

User: "Create a new support ticket for Acme Corp and assign it to Sarah."

AI calls:
tickets.create({ companyId, subject, description }) - > Meteor method "tickets.create"
tickets.assign({ ticketId, userId }) - > Meteor method "tickets.assign"

No separate AI API layer required — the assistant just uses your existing Meteor methods.

2. Internal automation

You can let automation agents interact with your backend directly.

Examples:

• Nightly data cleanup
• Auto-tagging uploaded documents
• AI summarizing activity feeds
• Intelligent retry of failed jobs

Instead of writing scripts that hit custom endpoints, the automation just calls methods as tools.

3. Instant REST API without writing controllers

A lot of Meteor apps eventually end up duplicating their logic:

Meteor method
↓
REST controller
↓
GraphQL resolver

Wormhole lets the method itself be the API, with generated OpenAPI docs and Swagger UI.

That means:

• external services
• microservices
• Zapier / Make / n8n
• backend jobs
• and agents with skills files

can call your logic without rewriting it.

4. AI developer tooling

One of the more fun uses is developer productivity.

If your methods are exposed via MCP, tools like Cursor, Copilot, or Claude can discover them automatically and interact with your app.

Example:

"Show me the latest orders in production."

The assistant can call:

orders.listRecent()

This becomes a live interface to your backend during development or debugging.

5. Rapid prototyping for integrations

Want to integrate with Slack, Notion, or an internal tool?

Instead of building a full API layer first, you can expose a few methods and start experimenting immediately.

Later you can tighten things down or move to opt-in mode.

Security-wise

Personally I recommend:

Wormhole.init({
  mode: 'opt-in',
  apiKey: process.env.API_KEY,
  exclude: [/^admin\./]
});

That way nothing is exposed unless you deliberately publish it.

TL;DR

The real benefit isn’t “opening your app to AI.”
It’s turning your existing server logic into a reusable tool layer for:

• AI agents
• automation
• integrations
• developer tooling
• external services

without rewriting your backend.

We gotta consider the supply chain risk @radekmie if uWebSockets is a single maintainer AND the legal consequences too/

This whole conversation was going on before

• faye-websocket: works and is already in the tree, but it looks unmaintained
• ws: probably the safest default choice, widely used in the Node ecosystem, actively maintained, and the migration cost looks small
• socket.io: likely too high-level for this use case since DDP already provides its own protocol and semantics
• uWebSockets: best raw performance, but single C++ maintainer (aand uWebSockets has had a somewhat unusual npm/distribution history deprecated uws, unpublished legacy versions, and periods where npm was explicitly discouraged by the maintainer, which makes it a riskier core dependency choice than ws)

So I think the practical path forward would be:

1. make native WebSocket the default client path
2. keep SockJS as an opt-in fallback for cases that still need it
3. replace faye-websocket with ws on the server side
4. clean up the transport boundary so other implementations can be explored later without hardcoding SockJS assumptions everywhere

Actually we’re in a bit of a conundrum post 3.4. Do we double down on the entire RS stack or only keep what’s useful? @nachocodoner

I think this would be a good opportunity for Meteor to issue a standardized linting guide as the current eslint ones have fallen out of favor. meteor/npm-packages/eslint-config-meteor at 86a32d99841e682fc23e52bb58f30ee0e8a88fc1 · meteor/meteor · GitHub

The 56 KB import for everyone, including people who want to disable it and use native WebSockets, is keeping me awake at night

See DISABLE_SOCKJS: dynamic import regression · Issue #14228 · meteor/meteor · GitHub

harry97:

This is huge great work.

It was some crazy two long nights and days as I had to get this going when I needed to ship a new version of my app to the users urgently and the version 4.2 I released earlier (never tagged it) had still lot’s of problems with 8 year old design (eg references to Cordova for a “Desktop-only app”. Enabling “desktopHCP” was just something I could have done later but now it’s working (fingers crossed, so far, we will see in the future).

Blown away by this and all the new Meteor progress

I’m happy to announce @a4xrbj1/meteor-desktop v5.0.0 — a major release that brings full Meteor 3.x compatibility to Electron desktop builds.

This is a continuation of the meteor-desktop package originally created by Paweł Wójtkowiak and previously maintained under @meteor-community. The fork lives at
GitHub - a4xrbj1/meteor-desktop: Build a Meteor's desktop client with hot code push. · GitHub.

Why v5?

Meteor 3.x dropped the web.cordova build target that meteor-desktop relied on. v5 rewrites the integration to work with web.browser architecture instead, and modernizes everything else along the way.

Key changes

• Meteor 3.x support — switched from web.cordova to web.browser architecture. Manifest acquisition, /__browser/ asset paths, isCordova detection, and autoupdate all updated.
• ESM / Electron 33+ — replaced deprecated registerStreamProtocol with protocol.handle + net.fetch(). Dev-server responses are patched for import.meta, global, and
  classic-script constraints.
• Hot Code Push improvements — cordova.js renamed to desktop-hcp.js, auto-injected into index.html, with 5 fail-fast guardrails in autoupdate.
• Dependency debloat — removed node-fetch, shelljs, lodash, rimraf, isbinaryfile, and del. All replaced with native Node.js APIs. The dist/ build step is gone — the package
  ships lib/ directly.
• 7 build validation gates (A1–A7) — catch broken bundles, missing files, and hash mismatches early. Every error path now throws or exits instead of silently continuing.
• Reliability — fs.rmSync race-condition fixes on macOS, chmodRecursive on all platforms, 13+ previously silent error paths surfaced as hard failures.

Install

meteor npm install --save-dev @a4xrbj1/meteor-desktop

Requires Meteor 3.0+ and Node.js 22+.

Links

• GitHub
• npm
• CHANGELOG

131 commits since the last release. Full details in the changelog.

Feedback, issues, and PRs welcome!

P.S.: build with the help of Claude Code and VSC Copilot

dupontbertrand:

As a separate email-preview package:

Make it a choice, not everybody wants to use it.

Thanks, you’re on a roll, Bertrand.

I will have to look how I can wire in my existing API keys, so that I can authenticate against multiple API keys. I think that is something that needs a bit more expansion. My use case is that users can create their own API keys and have limited access to the API.

Here is my packages file

cultofcoders:redis-oplog
[email protected]
[email protected]             # Packages every Meteor app needs to have
[email protected]       # Packages for a great mobile UX
[email protected]                   # The database Meteor supports right now
[email protected]            # Reactive variable for tracker

[email protected]   # CSS minifier run for production mode
[email protected]    # JS minifier run for production mode
[email protected]                # ECMAScript 5 compatibility for older browsers
[email protected]              # Enable ECMAScript2015+ syntax in app code
[email protected]              # Enable TypeScript syntax in .ts and .tsx modules
[email protected]            # Server-side component of the `meteor shell` command
[email protected]  # Update client in development without reloading the page

[email protected]             # Define static page content in .html files
react-meteor-data       # React higher-order component for reactively tracking Meteor data
[email protected]
ccorcos:subs-cache
montiapm:agent
aldeed:simple-schema
reywood:publish-composite
ferjep:persistent-session
[email protected]
strigops:job-collection
montiapm:profiler

xet7:

What kind of hardware/CPU/RAM and software does it require to run millions of concurrent users at scale with Meteor 3.5 ?

More importantly, why can’t I run Meteor 3.5

What is the benefit that is greater than the added security flaw and attack front?

mikaknu:

This might be useful to a lot of people getting into meteor 3.4 and rspack

Thanks a lot for this link, this will help for sure as past experiences with the Beta versions didn’t work out.

Steps to reproduce:

1. Uninstall system node
2. Verify. which node should be blank, and meteor node --version should return meteor node’s version as expected.
3. meteor create test and cd test
4. Make sure rspack is enabled, cat .meteor/packages | grep rspack
5. meteor run

Expected:
App starts successfully, and uses Meteor’s node.

Actual:

=> Started proxy.                             
=> Started HMR server.                        
[Rspack Client Error] /usr/bin/env: ‘node’: No such file or directory

[Rspack Server Error] /usr/bin/env: ‘node’: No such file or directory

=> Started MongoDB.                           
   Loading plugin `rspack` from package ...  \

Additional information:

Verbose
=> Started proxy.                             
=> Started HMR server.                        
[i] Meteor Npx prefix: /home/<username>/.meteor/packages/meteor-tool/.3.4.0.1tu4sphekowk++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npx
[i] Meteor Npm prefix: /home/<username>/.meteor/packages/meteor-tool/.3.4.0.1tu4sphekowk++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm
[i] Meteor app ignores: _build/test/** _build/main-prod/** node_modules/** client/** imports/** server/** tests/** .gitignore .swcrc package-lock.json rspack.config.js !client/*.html !client/*.css !server/*.html !server/*.css
[i] App entrypoints: {
  "mainClient": "_build/main-dev/client-meteor.js",
  "mainServer": "_build/main-dev/server-meteor.js",
  "testClient": "_build/test/client-meteor.js",
  "testServer": "_build/test/server-meteor.js"
}
[i] App custom script: /__rspack__/client-rspack.js
[i] Rspack DevServer Port: 8080
[i] Rspack default config: /home/<username>/workspace/test/node_modules/@meteorjs/rspack/rspack.config.js
[i] Rspack custom config: /home/<username>/workspace/test/rspack.config.js
[Rspack Server Error] /usr/bin/env: ‘node’: No such file or directory

[Rspack Client Error] /usr/bin/env: ‘node’: No such file or directory

=> Started MongoDB.                           
   Loading plugin `rspack` from package ...  \

meteor --version
Meteor 3.4

meteor node --version
v22.22.0

meteor npm --version
10.9.4

Ubuntu 22.04.05 LTS

dupontbertrand:

And one thing though : full TypeScript might be overkill for a Blaze rewrite. The original codebase is plain JS and most Blaze users aren’t TypeScript shops. You could get the same benefits (typed APIs, IDE autocompletion) with JSDoc type annotations + a .d.ts file, without forcing contributors to write TypeScript. Just a thought

Absolutely agree with that PoV

dupontbertrand:

I can open a MR with the help of Claude

Same for @wreiske :

As a user of Claude Code you should take a look into this package (actually the whole ecosystem):

“Greenhouse closes the last manual loop in the os-eco toolchain. It polls GitHub for pre-triaged issues, creates seeds tasks, dispatches overstory runs, and opens PRs when agents finish. The only human touchpoint is merging the PR.”

I’m using it extensively since a month and man, the speed of progress is huge.

Also watch this video which explains how we can manage open source packages way more effective and have a minimum of human intervention. This would speed up the work:

The Agentic Engineering Ladder

Good catch I’m going to look into that

• v2.51.0-beta.1 — published August 29, 2025 (newest overall)
• v3.0.0-beta.16 — published August 8, 2025 (latest in the 3.x beta line)
• v3.0.0-beta.15 — June 5, 2025
• v2.50.1 — February 3, 2025

@zodern: will there be a stable 3.x version published and if so, when?

It seems this time, instead of being a fallback, it always uses the dynamic import unless manually configured to not use sockjs. Since apps by default use sockjs, most apps would have to wait for the dynamic import before being able to start the DDP connection.

It would be interesting to see what the performance gain is compared to Meteor 3.4 with sockjs.

For the high cpu usage, it does seem related to the number of sessions: it does go down when the sessions go down. If you are using continuous cpu profiling, you can look at what was causing the high cpu usage.

I’m working on some new tools to help with memory leaks. If you send me a message with the app you are monitoring, I can give you early access.

So I’m trying to concentrate all DDP PRs in 3.5, it’s a few prs but is everything about the same module

We will have a beta version for 3.4.1, the official 3.4.1, so I think we have enough time to experiment with 3.5.

It would be nice to see the packages that you use for your app.

what’s new?

• DISABLE_SOCKJS=1 fully functional end-to-end (client + server), PR #14206

  • PR #12007 (Meteor 2.7.2) introduced the DISABLE_SOCKJS env var but only implemented the client side. The server kept creating a SockJS server regardless.
  • This PR completes the implementation: when DISABLE_SOCKJS=1 is set, the server now uses native WebSocket instead of SockJS.
  • Performance gains: warm browser reload is ~5x faster with DISABLE_SOCKJS=1, eliminates the /sockjs/info?t=... XHR (fired on every connection) and the SockJS dynamic chunk (~56 KB).

• ddp-client: fix default DDP connection URL for mirror domains, PR #14189

  • Without this change, mirror domains could all end up connecting to a single WebSocket endpoint derived from Meteor.absoluteUrl() instead of the specific domain the user opened.
  • The fix uses the protocol from Meteor.absoluteUrl() but takes the host (with port) from window.location.host.
  • No behavior change for apps that already set DDP_DEFAULT_CONNECTION_URL.

Big Thanks to Our Contributors

Community contributions are the backbone of Meteor 3.5.

• Contributors: @dupontbertrand @alextaaa @mvogttech

We plan to give some love to this soon.

It is in our roadmap: Roadmap | Docs

What is the state of typescript and type generation for meteor packages?

I’m not familiar with it meteor package development, but is there “tsup” or “tsdown” equivalent for meteor packages?