Build a real-time chat or multiplayer game with WebSockets on BrewInTH
Have AI build a live chat, a multiplayer game or a self-updating screen with WebSockets on BrewInTH: limits per package, reconnecting, and keeping state safe.
You want a chat room where new messages pop up without a refresh, a word game your friends play at the same time, or a shop screen that updates the queue the moment someone books. All of these use the same trick: a WebSocket, a connection the browser keeps open to the server so messages can flow both ways at any moment.
This article explains what WebSockets are, what they're good for, how to have AI build one, and how to put it on BrewInTH without configuring a server yourself — plus the per-package limits worth knowing and how to make your app reconnect on its own when a connection drops, the part AI-written code most often forgets.
In short
✅ BrewInTH accepts WebSockets on your project's usual site name over HTTPS (wss://), your own domain included
✅ It needs an app project such as Node.js, Python or Go; a static-only site can't answer a WebSocket
✅ 32 open connections per project on Free, 500 to 4,000 on paid packages
✅ A connection silent for 10 minutes is closed, and every new release cuts existing ones, so ping and reconnect
✅ Keep messages, scores and room state in Redis or a database, not only in your app's memory
What is a WebSocket, and how is it different from a normal page?
A normal web page works as question and answer: the browser asks for a page, the server sends it back, done. To find out whether there's a new message, the browser has to ask again every few seconds — slow and wasteful.
A WebSocket keeps one line open. When something happens, the server tells the browser straight away, and the browser can answer just as fast. Messages arrive in a fraction of a second, which suits:
- Live chat — a team room, a "chat with us" box on a shop, a classroom chat
- Multiplayer games — word games, Kahoot-style quiz races, turn-based board games
- Screens that update themselves — queue displays, sales dashboards, kitchen order status
- Working together — a shared idea board, live voting during a meeting
How WebSockets work on BrewInTH
Every request to a site on BrewInTH passes the platform's front door (the edge) before it reaches your app, and WebSockets are no different. There are only a few things to know:
- Same address as the site. If your site is at
https://your-name.host.brewinth.net, the browser connects towss://your-name.host.brewinth.net/ws(use whatever path your app listens on). Once your own domain is connected, that works too. - Always
wss://. Every BrewInTH site is HTTPS, and browsers refuse a plainws://from an HTTPS page. The safe way is to build the address from the current page: ` - It has to be an app. A WebSocket needs a server program to answer it. A project of plain HTML/CSS/JS files has none; use Node.js (the
wslibrary or Socket.IO), Python (FastAPI, websockets) or Go. - One port. The pages and the WebSocket live in the same app, on the port the app reads from
PORT. No extra port to open.
Limits to know before you start
Open connections per project — the number of people with the page open at the same moment:
| Package | Open at once |
|---|---|
| Free | 32 |
| Starter / Seed | 500 |
| Maker | 1,000 |
| Growth | 2,000 |
| Pro | 4,000 |
Past that number, new connections are refused until someone leaves. Free is right for trying things out, a game with a few friends or one classroom; for a public site, pick a paid package (prices in Which BrewInTH package should you choose?).
Silent for 10 minutes = closed. If nothing travels in either direction, the connection is closed. Have the app send a ping or a tiny message every 30-60 seconds; most libraries, Socket.IO included, already do.
One connection lives at most 24 hours. A screen left on all day, such as a queue display, should simply reconnect.
It counts toward bandwidth. WebSocket traffic counts toward the package's monthly data like page views do. Text chat uses very little, but if you push pictures or large payloads every second, keep an eye on the Usage page.
Connections drop: make your app reconnect by itself
This is the most important part. WebSockets drop for many reasons, and most aren't bugs in your code:
- A new release. When a new version goes live, connections to the old one are closed within about half a minute, so everyone reconnects to the new version.
- More than 10 minutes of silence, or 24 hours reached.
- The user's network — a phone switching from Wi-Fi to 4G, or a locked screen.
- A sleeping Free site. A Free site with no visitors for a long time goes to sleep; the first connection while it wakes up is refused. Wait 5-10 seconds and try again (more in Why does a free site load slowly the first time?).
The fix is the same in every case: have the browser reconnect with growing waits (1, 2, 4, 8 seconds, at most 30), and once it's back, load the latest state — say the room's last 50 messages or the game's current scores.
Why state belongs outside the app
On every release the old app stops and the new one starts from scratch. Anything kept only in program variables — messages, scores — disappears with the old one.
- Redis suits fast-changing data: who is in which room, scores mid-game, recent messages. One per project, not counted against your database allowance, and the platform hands your app
REDIS_URL. More in What is Redis and how does it make a site faster? - Your main database (PostgreSQL, MySQL, MongoDB) suits chat history you keep for good, past game results and user accounts.
Have AI build it and put it on BrewInTH
If your coding agent is already connected to a BrewInTH project, send a prompt like this and adapt the app to taste:
Build a one-room real-time chat site with Node.js and WebSockets (the ws library).
- Users pick a nickname before joining and see new messages instantly, no refresh.
- The pages and the WebSocket live in one app listening on process.env.PORT.
- The browser builds the address from location (https = wss), path /ws.
- Ping every 30 seconds and reconnect on a drop after 1, 2, 4, 8 seconds, at most 30.
- Keep the last 50 messages in the project's Redis (read REDIS_URL) and load them on every connect.
- Limit messages to 500 characters and make sure no HTML in a message runs on other people's pages.
Then deploy it to BrewInTH, creating Redis for the project if it has none.
After it's live, test with two windows: send from one and check the other sees it.For a multiplayer game, use the same pattern and spell out the rules:
Build a take-turns drawing and guessing game for 2-8 players with WebSockets.
- A player creates a room and gets a 4-character room code to share.
- The server decides scores and timing; never trust values sent by the browser.
- Keep rooms, players and scores in Redis so a player who drops can rejoin the same room.
- Delete rooms that have been empty for more than 30 minutes.No coding agent?
Have a chat AI write the code from the prompt above, then upload it through the Upload and go live page. If the code uses Redis, the platform creates one for the project (that page is still in BETA).
See how many people are connected
If statistics are switched on for your account, the project's Statistics tab shows WebSocket sessions, average connection time and data sent, counted by the platform with no code in your app. It tells you whether people really use your game or chat room, and how close you are to the package's limit.
Security checklist
- Check who connects. If a room is for members only, have the app verify the session or token when the connection opens, rather than letting anyone in.
- Don't trust the browser. Scores, timers and who won are worked out on the server.
- Limit message size and rate, so nobody can flood a room until it's unusable.
- Show messages as text, never as HTML.
Frequently asked questions
Do I need to switch anything on in BrewInTH for WebSockets?
No. WebSockets work on every app project from the start; the app just has to accept the connection on the same port as its pages.
Can I use Socket.IO?
Yes. Socket.IO opens its WebSocket on the site's own address and has pings and reconnecting built in, which fits the silence limit nicely.
Can a plain HTML static site do chat?
It can't answer a WebSocket itself, because there's no server program. Turn it into an app project — for example, ask AI to add a small Node.js server that serves your existing pages and handles the WebSocket too.
Why does everyone drop at once after I update the site?
That's expected: when the new version goes live, connections to the old one are closed. If the app reconnects on its own and reloads its state from Redis or the database, users only notice a hiccup of a few seconds.
What happens when more people connect than my package allows?
New connections are refused until someone leaves; those already connected carry on. If it happens often, move to a bigger package.
Summary
WebSockets turn an AI-built site into a live chat, a multiplayer game or a self-updating screen. On BrewInTH they work straight away on your site's own name over wss://, as long as the project is an app. Remember three limits — open connections per package, 10 minutes of silence, and new releases cutting old connections — and have AI write reconnecting and keep state in Redis or a database from day one.
Start your first project for free →