How a Forge64 app runs

A visitor's request to an app hostname goes to the global edge, then to the Forge64 Cloud server's TLS front door, then to the Forge64 host router, then to the app's container. The host router looks the hostname up in a routing table and refuses unknown hosts.

• BuiltEdge, then the TLS front door on port 443, then the host router, then the app's container. This chain has been exercised end to end for the app.forge64.dev hostname.
• Rolling outGenerated apps are served from the apps domain (forge64.app by default), separate from the marketing site on forge64.dev. The move of app hostnames to that domain is in progress.

Builds run in isolated build jobs with no container daemon on the host. The resulting image runs as a scheduled job with a memory limit set by the plan. The scheduler restarts a failed app a bounded number of times, then stops instead of looping.

• BuiltOne scheduled job per app with a bounded restart and reschedule policy and a single cluster policy for what an app may do.
• Rolling outStatic apps can be built and served without a running container.
• RoadmapMulti-node hosting with failover. Production runs on a single server today.

Each app gets its own Postgres database in a shared Postgres 17 cluster on the data host, with its own login roles. The app receives its connection string as an environment variable at deploy time. See the Security page for the isolation model.

• BuiltOne Postgres database and two login roles per app.
• Rolling outPer-tenant connection pooling.
• RoadmapMore than 250 tenant databases per cluster (sharding across clusters).

Uploaded files and exports live in object storage. The control plane (sign-in, projects, plans, queues and the deploy saga) runs on a global edge network.

• BuiltControl plane on a global edge network (API, queues, key-value and relational state, object storage).
• BuiltPer-app file storage allowance by plan.

• BuiltCertificates are issued on demand, but only for hostnames the Forge64 API approves. Unknown hostnames get no certificate.
• Rolling outA corrected approval gate and a restricted admin route are written and tested but not yet applied to the production server.
• Rolling outCustom domains require a DNS TXT ownership proof and a pointing check, are re-verified every 24 hours, and have issuance caps because certificate authorities limit new certificates per registered domain.
• BuiltCustom domains are available on paid plans only; the Free plan uses a forge64.app subdomain.

To keep hosting cost bounded, apps on the Free plan sleep when idle and wake on the next visit. Sleeping changes the container count to zero; it does not delete the app or its database. The master switch for sleep is off in production at the review date.

• Rolling outScale to zero: the Free plan sleeps after 15 idle minutes with a daily awake-time budget; Pro sleeps after 30 idle minutes; Business and Enterprise do not sleep. The first request after sleep waits for the container to start; the cold-start time has not been measured on real infrastructure.
• Rolling outThe host router caps concurrent connections and request rate per app, and the plan sets the memory limit and the number of always-on app slots (see the Scale page).
• BuiltHard caps on every metered resource, with an owner-set overage spend cap on paid plans and no overage on Free.

Where does a Forge64 app run?

In a container on Forge64 Cloud, behind an automatic-TLS front door and a host router. The control plane runs on a global edge network.

Does each Forge64 app get its own database?

Yes. Each app gets its own isolated Postgres database and its own login roles, in a shared Postgres 17 cluster.

Is HTTPS included for my app and custom domain?

Yes. Certificates are issued automatically for hostnames the Forge64 API approves. Custom domains are on paid plans and need a DNS ownership proof first.

What happens to my app when it is idle?

On the Free plan the app sleeps after a period of inactivity and wakes on the next visit; the app and its database are kept. Paid plans have always-on slots. The sleep master switch is off in production at the review date.

Does Forge64 run in more than one region or server?

No. Production app hosting is a single server today. Multi-node hosting and customer-selectable data residency are on the Roadmap.