Web services

A web service runs your application and exposes it through a public HTTPS URL. Use it for Django, Laravel, Express, FastAPI, Next.js server rendering, and other applications that execute code for incoming requests.

Create a web serviceCopy Anchor Link

1. Open your project in the Openstead dashboard and create a Web Service.
2. Choose a GitHub repository or a container image. For a repository, select the branch and application root.
3. Review the detected language, build method, build command, and start command.
4. Select an instance plan. Add environment variables and any required persistent disk.
5. Configure the application's listening port and, preferably, a health check path.
6. Deploy. If a paid month requires activation, complete the displayed checkout first.

Follow the deployment's logs until it is Live, then open the URL shown on the service.

Bind to the configured portCopy Anchor Link

Your server must listen on 0.0.0.0 and the port configured for the service. Openstead supplies that value as the runtime PORT variable. Detection commonly selects port 3000 for Node.js; the general configuration default is 8000. Check the actual service settings rather than assuming a fixed port.

For Express:

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

For an ASGI application:

uvicorn main:app --host 0.0.0.0 --port "$PORT"

Binding only to localhost prevents the platform from reaching the application. The application normally serves HTTP inside the service; Openstead handles public HTTPS.

Configure a health checkCopy Anchor Link

Add a lightweight route such as /health that returns a successful response when the application is ready. Set Health check path to that route. Without a path, readiness checks verify that the configured port accepts connections.

Health checks must work without a browser login. See Health checks for accepted responses and common failures.

Connect databases and store uploadsCopy Anchor Link

Use the database's private connection details from the same permitted network scope. Keep credentials in environment variables, never in client-side JavaScript.

Persist user uploads with object storage or a paid persistent disk. A service with a local persistent disk runs one instance. Applications that need multiple instances should use shared external storage, sessions, and queues.

Operate the serviceCopy Anchor Link

The service navigation includes deployments, logs, metrics, environment variables, and compute settings. Paid running application instances also support shell access and one-off jobs. Use rollbacks to return to an earlier successful release; a rollback does not reverse database writes.

Use access controls to restrict incoming IP addresses or configure maintenance mode. Confirm the routing change's result before assuming the new policy is serving.

Free web instances sleep after inactivity and share a monthly runtime allowance. Read Free instances before using a free instance for a workload that must stay awake.

Next: Next.js, Django, Laravel, or Node.js.