How apps run

Recognising the code and building it#

At the start of every deploy Meghly reads the code and decides what kind of app it is:

For each kind and version Meghly uses its own build — you need no Dockerfile. Each has its own page under Guides: ASP.NET Core, Node.js, Python, PHP / Laravel, WordPress, Static sites.

For anything else (Go, Rust, Java …), or for a build of your own, bring your own Dockerfile — but a Dockerfile in the repository is not used by itself: set the app's kind (What is it?) to Dockerfile. See Your own Dockerfile.

A build may take up to 15 minutes; the whole log of every build stays on the deploy's page.

Port#

Meghly gives the web process its port in the PORT environment variable (usually 8080, or the port Detect found). Your app must listen on that port, on 0.0.0.0 rather than localhost.

const port = process.env.PORT || 8080;
app.listen(port, "0.0.0.0");

For frameworks such as ASP.NET Core, Laravel or Django Meghly sets this up itself; there is usually nothing to do.

The app is reached from outside only through Meghly's router, over HTTPS. WebSockets (SignalR, socket.io, Laravel Reverb) work.

For game servers, VoIP or IoT that need TCP/UDP ports of their own, see Realtime and ports.

Processes: web, worker, cron#

An app can have one process or several, each in its own container:

The app's Processes page adds processes and changes replicas and memory. A process that falls over is started again by itself.

Procfile#

As on Heroku, Render or Railway, a Procfile at the repository's root is read:

web: node server.js
worker: node jobs/worker.js
release: npx prisma migrate deploy

• web: — the web process's command.
• release: — run once before every deploy (see below).
• any other name — a worker.

Commands run through sh -c, so $PORT and && work. Up to 10 processes.

Where to write files#

Every container's file system is read-only, for safety. An app can write to:

• /tmp — temporary, emptied on restart.
• a volume — add one on the app's Files & backups page (for example /app/storage). Keep uploads, images and keys that must survive a restart there.

Deploys without downtime#

1. The new version starts next to the old one.
2. Meghly checks its health: GET / (or your Health check path) — a 2xx or 3xx answer passes.
3. Only then does traffic move to the new version, and the old one stops.

If the health check does not pass, the deploy fails and the old version keeps running. The deploy's page then shows the app's last log lines.

Release: database migrations#

Migrations run once before every deploy, in a container of their own, before traffic moves to the new version. If a migration fails the deploy stops and the old version keeps running.

• Laravel (php artisan migrate), Django, Prisma and Alembic are recognised by themselves.
• For anything else, set your own command in the app's General → Release command, or write release: in the Procfile.

The release gets the database's migration login, which may create and change tables. The running app gets the runtime login — reading and writing, but not changing tables. So code that changes the schema as the app starts (Database.Migrate(), EnsureCreated()) will not work there; that is the release's job.

Rollbacks#

In Deployments, one click takes you back to any earlier deploy — with that deploy's image and variables.

Sending mail out#

Apps cannot send mail straight out on port 25 (to keep spam off the network). To send mail, use SMTP submission (port 587) with your own Meghly mailbox or any mail service.

Limits#

Your plan's RAM, CPU and disk are shared by all your apps. A process that goes over its memory is stopped and started again; a full disk stops writes. The app's Usage page shows what is used, and Logs shows the app's own log.