Hosting and data
Egbe hosting builds your application’s Git repository using its Dockerfile and publishes a live HTTPS address. Your agent can create an Egbe-hosted repository, push the intended revision, deploy it and inspect build or runtime logs. See the deployment instructions.
Publish and verify
Section titled “Publish and verify”The app must listen on 0.0.0.0 using its exposed container port. A deployment starts asynchronously, so acceptance of the request is not completion. Your agent should check the serving revision, open the returned customer URL and exercise the important journeys.
Applications can scale to zero. A warm-instance option avoids that cold start but consumes resources continuously; check its current cost before choosing it. Runtime configuration is distinct from build configuration: public values compiled into browser code must be present when the application is built.
Choose an address
Section titled “Choose an address”Every app has a canonical *.n.egbe.app host. Its first deployment attempts to claim a shorter <name>.egbe.app address. Use the response’s url for customers; it reflects the assigned address and falls back to the canonical host.
A business normally has one short alias, which can move between its apps. A custom domain requires Egbe admin setup and an enabled allowance. The owner then adds the exact DNS records returned by Egbe and waits for TLS readiness. The canonical address keeps working during that setup. Follow the domain instructions; this flow connects an owned domain rather than purchasing one.
Store customer data
Section titled “Store customer data”For a database-backed product, the deployment can attach PostgreSQL and inject DATABASE_URL into the app. Your application owns its tables and repeatable migrations; provisioning a database does not create the product’s schema. Apps in the same business share the attached database schema.
The runtime has a read-only root filesystem. Writable temporary directories are erased on restart, so container files or local SQLite are unsuitable for durable customer records. The supported PostgreSQL path is the attached database, not an arbitrary external PostgreSQL host.
The database instructions cover bounded queries, exports and correction of individual rows. They do not provide arbitrary database administration. A managed Convex backend has a separate provision-and-deploy path; check the project’s supported offering before selecting it.
Before promising saved work, verify saving, reloading and returning through the live customer interface. Before an update, retain a representative existing record and confirm it still recovers afterward. Browser-only storage should be described as browser-only; it does not establish account or cross-device recovery.