Build a mobile app backend with AI and host it on BrewInTH

Your Flutter, React Native or Expo app looks great in the simulator. Then you want other people to use it, and the same questions come up: where does user data live, how does sign-in work, which address does the app call? The answer is a backend that stays online.

This guide walks through building a mobile app backend with AI and hosting it on BrewInTH: asking the AI to write the API, setting the health check path, connecting a database, and the things a mobile app has to handle, such as a sleeping server, request limits and keys that must never ship inside the app.

In short
✅ A mobile backend is a server app (Node, Python, PHP, Go, Java, .NET, Ruby, Bun) that answers JSON over HTTPS
✅ An API with no home page needs a health check path such as /health, or the release does not pass
✅ REST, WebSocket, server-sent events and gRPC all work on the same address
✅ On the Free plan the server sleeps when idle; the app should retry on a 503 runtime_waking
✅ Secret keys stay on the backend; never bake them into the app

What a mobile backend is

The app on the phone shows screens and takes taps. Anything that has to be shared lives on a server: user accounts, data every device sees the same way, payments, notifications. The app sends a request such as GET /api/posts to the backend and gets JSON back.

On BrewInTH a backend is an ordinary app project. Use the language you like, Node.js, Python, PHP, Go, Java, .NET, Ruby or Bun, and it gets an HTTPS address right away, for example https://myapp-api.host.brewinth.net.

Build the backend with AI, step by step

1. Design the API before the AI writes code

Tell the AI what the app does and which screens it has, and ask for the list of endpoints first. Say it is a savings tracker:

I am building a Flutter app called "Save Daily" where users log their savings each day.
Design a backend as a REST API that answers JSON:
- sign up / sign in with email and password, returning a token (JWT)
- add / edit / delete / list the user's own entries
- a monthly summary
- GET /health answering {"ok":true}, used to check the server is ready
Use Node.js + Express + PostgreSQL.
Show me the endpoints and the tables first, then write the code.

2. Ask for code that is ready for a server

A few more lines make the code go live on BrewInTH in one pass:

Write the backend as designed, and:
- listen on 0.0.0.0 and the port from process.env.PORT
- read the database address from process.env.DATABASE_URL and JWT_SECRET from an environment variable
- create the tables with migrations, not by hand
- answer every error as JSON with the right status code (400, 401, 404, 500)
- never write passwords or keys into the code
Then deploy it to BrewInTH with the link and token I will give you, set healthPath to /health,
and confirm with site_check that /health answers 200.

An AI connected to BrewInTH through the link and token creates the database, sets the secrets and publishes on its own. Connection values such as DATABASE_URL are written for you.

3. Set the health check path

Before a release goes live, BrewInTH calls GET on one path of your app and expects a 2xx or 3xx answer within 5 minutes. The default is /, which websites have anyway, but a mobile API usually has no home page and answers 404 on /, so the release fails.

Two ways to fix it:

• tell the AI to set healthPath to /health (the prompt above already does);
• or set it yourself: on the Releases tab press Advanced options (build / start / port) and fill in Health check path (GET must answer 2xx/3xx).

If it still fails, read the [readiness] lines in the release log. They say what the check saw: a 404 means the wrong path, a 500 means the app is missing a setting or a table.

4. Put the API address in the app

Ask the AI on the app side to keep the API address in one constant, such as API_BASE = "https://myapp-api.host.brewinth.net", so switching to your own domain later is a one-line change.

What works, and the limits worth knowing

• REST / JSON works out of the box.
• WebSocket and server-sent events for chat or live updates use the same address. Free allows 32 open connections per project, paid plans 500 per 0.5 CPU of the plan. A connection silent for more than 10 minutes is closed, so the app should reconnect on its own.
• gRPC: requests with Content-Type: application/grpc travel as HTTP/2 end to end, trailers included.
• Outbound calls to notification services, payment providers or another AI work on every port except 25 (for email use 465/587 or the provider's API).
• Request size: 20 MB on Free, 400 MB on paid plans, enough for photo uploads from a phone.
• Response wait: if the app sends nothing back, the request is cut after 2 minutes (Free) or 10 minutes (paid). For long jobs, answer at once and let the app ask for the result later.
• Rate limit: 60 requests per second per IP on average (bursts up to 300). Normal use never gets near it.

The Free plan sleeps: make the app retry

On the Free plan an app sleeps after a while with no requests. The next request wakes it, and while it starts (roughly 10-40 seconds) the API answers 503 with this JSON:

{ "error": "runtime_waking", "retryAfterSeconds": 5 }

Tell the AI on the app side how to handle it:

If the API answers 503 with error "runtime_waking", wait retryAfterSeconds and try again,
up to 8 times. Meanwhile show "Connecting to the server…" instead of an error message.

Once the app has real users, a paid plan lets you pick the idle time or never sleep, under Autosleep. The database does not sleep and no data is lost.

Security: what never goes inside the app

Anyone can unpack an app they downloaded. Whatever is inside the app is public.

• Fine inside the app: the API address and the user's token received after sign-in.
• Backend only: database passwords, JWT_SECRET, payment keys, AI service keys. Keep them in the project's secrets (the App settings tab) and let the app go through your API.
• Check permissions on the backend every time. Never trust a user id the app sends; read it from the token.

For photos users upload, switch on Persistent storage (/data) on the App settings tab and write the files there. Files written anywhere else disappear with the next release.

Watch the video (in Thai)

▶ From creating a project to opening the site (1:30)
Watch on YouTube

Frequently asked questions

Do I need CORS?

Native apps (Flutter, React Native) are not affected by CORS because they do not run in a browser. You only need it when a web page on another domain calls the same API (Expo for web included). Ask the AI to allow your own domain, not *.

I already use Firebase. Do I still need a backend?

Not if Firebase covers everything. A backend of your own helps once you need to hold a key that can cost money, connect payments or run complex rules, and it can call Firebase too, since outbound internet works.

Can I send push notifications?

The backend can call a notification service over HTTPS, since every port except 25 is open outbound. Keep that service's keys in the secrets.

Can the API use my own domain?

Yes, on a paid plan, for example api.yourapp.com. Change API_BASE in one place. The BrewInTH address keeps working, so older app versions your users have not updated still connect.

Can I build the backend from my phone alone?

Writing the code and deploying it needs a coding agent on a computer, such as Claude Code, Codex, Cursor or Windsurf. Checking status works from a phone.

Summary

A mobile backend on BrewInTH is an app project that answers JSON. Let the AI design the endpoints first, write code that reads the port and secrets from environment variables, set the health check path to /health, and make the app handle the 503 while the server wakes. Your app then has a real server that every user's device shares.

Start your first project free →

Related articles

• Which database: PostgreSQL, MySQL, MongoDB or Redis
• Keep API keys and passwords safe with project secrets