📰News from @meteorjs release 3.5 DDP Session Resumption is new in Meteor.js 3.5. When a client drops and reconnects within a grace period (default 15s), Meteor resumes the SAME session instead of tearing it down and rebuilding from scratch. ⚙️ What that means in practice: onConnection doesn't re-fire. The client keeps its original connection ID. No full session re-init, no data re-fetch. Pending method calls survive, active subscriptions pick up where they left off. 📱 This is built for real networks: mobile handoffs, sleeping tabs, flaky Wi-Fi. Fewer spinners, less stale data. 🖥️And the CPU wins are real — no more reconnect storms hammering your server after load-balancer timeouts (looking at you, Cloud Run). Only ungraceful disconnects resume. Intentional logout or kick still tears down cleanly. Two tunables if you want them: disconnectGracePeriod (15000ms) and maxMessageQueueLength (100). Built by github.com/vlasky 👏 meteor update --release 3.5 github.com/meteor/meteor/pul…

This is a huge step forward! A most wanted feature and still compatible with your Meteor 3 apps! @meteorjs @MongoDB

We sat down with the core team to walk through everything new in this version: youtube.com/watch?v=SbZ1hvVE…

Meteor 3.5 is here ☄️ Big changes: • MongoDB Change Streams now ON by default (~40% more scalability, no more OOM crashes) • Pluggable DDP transport + uWebSockets for lower latency • DDP session resumption on reconnect • accounts-express for authenticated REST • Node.js 24 LTS 🔥

Meteor makes real-time apps feel effortless. But the same automatic reactivity that feels magical early on can quietly slow things down as your app grows. A new guide breaks down how re-renders work in Blaze vs React (and how to keep them fast): blog.galaxycloud.app/reducin…

We just released a complete guide to adding Stripe payments to a Meteor 3.x app: Payment Intents created server-side, transactions stored in MongoDB, and signature-verified webhooks that keep payment state accurate. End-to-end, deployed on Galaxy: blog.galaxycloud.app/meteor-…

Read more: the full step-by-step guide covers GitHub Secrets, monitoring the pipeline, and a troubleshooting section for the most common deploy errors. blog.galaxycloud.app/ci-cd-f…

Once the basics work, harden it for production: Pin your Meteor version in .meteor/release. Split staging and production into separate workflows. Commit package-lock.json. Rotate your session token periodically. CI/CD is a foundation, not a ceiling.

On deploy, Meteor builds a production bundle, authenticates with your session token, and uploads it. Galaxy then builds a Docker image, starts the container, injects your env vars, and routes traffic. No server setup on your end. Galaxy handles the infrastructure.

The workflow lives in .github/workflows/deploy.yml and runs on every push to main. Its steps: check out code, install Meteor, restore the session, write settings.json, then run meteor deploy. Minimal on purpose, so each moving part is easy to read.

Your app settings hold sensitive values like MONGO_URL and ROOT_URL. Store them as a second secret, METEOR_SETTINGS, and the pipeline writes settings.json at deploy time. That file never has to exist in your repo or on your machine. Keep secrets out of git.

How does GitHub Actions get permission to deploy? It uses your Meteor session token, the same one created when you run meteor login locally. You generate it, base64-encode it, and store it as a GitHub secret named METEOR_SESSION. Never commit it anywhere.

The goal: every push to your main branch automatically triggers the same sequence. GitHub pulls your code, installs Meteor, authenticates with Galaxy, injects your settings, and ships the build. No terminal, no human error, same result every time.

Deploying a Meteor app manually works fine at first: run meteor deploy, watch the logs, move on. But once the app grows, one missed env var or a badly timed push can take down production. A CI/CD pipeline removes that risk. Here's how to set one up for @CloudByGalaxy. 🧵

A Meteor gotcha that catches React developers: inside a publication, the context 'this' gives you — this.userId, this.ready(), this.stop(). Arrow functions have no 'this' of their own, so they silently break access to it. Always use a regular function in a publication.

Still on Meteor 2? 👀 It reached End-of-Life in December 2025, which means no more updates of any kind. But hey, migrating to Meteor 3 is more approachable than it looks. This new guide on the blog covers what changed, what breaks, and how to fix it: blog.galaxycloud.app/meteor-…

Check what's new: forums.meteor.com/t/meteor-3…

Meteor 3.5-rc.1 is out! Change Streams on by default, a pluggable DDP transport (uWebSockets), DDP Session Resumption, MongoDB Collation, Node.js 24.15.0, and more. This is the final checkpoint before 3.5. Give it a try: meteor update --release 3.5-rc.1

@meteorjs release 3.5-rc.1 is out 🎊🎉🥳 All the details: Change Streams on by default, the new pluggable DDP transport (uWebSockets), DDP Session Resumption, `accounts-express`, async DDPRateLimiter matchers, MongoDB Collation, the EJSON/DDP performance batch, Node.js 24.15.0, and the full list of fixes, are already covered in the main post here: forums.meteor.com/t/meteor-3… Give it a try: meteor update --release 3.5-rc.1 This is the final checkpoint before 3.5 official, so the most valuable thing you can do right now is test your apps against `3.5-rc.1` and report anything unusual here in the thread. Your feedback is what gets us to a solid stable release. 🙏 Thanks again to everyone who contributed and tested along the way!

Type safety in a Meteor app starts with your collections. Pass an interface as a generic to Mongo.Collection, and every insert, update, and query gets checked against it. Insert a document with a missing field or wrong type, and the error shows up in your editor, not in prod.