Deploy your first application
Connect GitHub, review detected settings, and deploy a web application or static site.
This guide takes an application already in GitHub and publishes it on Openstead. You need access to the repository and a verified Openstead account.
1. Create a project
Open the Openstead dashboard and select your workspace. Create a project with a recognisable name. Openstead creates a Production environment for a new project.
Projects organise related services; they are not billable server instances. See Projects and environments for a production and staging layout.
2. Choose the service type
Select New and choose Web Service if your application runs a server process. Choose Static Site if its build produces only HTML, CSS, JavaScript, and other static assets.
A Next.js application using server rendering needs a web service. A Vite frontend that builds into dist normally needs a static site. A Laravel application needs a web service and a separate MySQL database.
3. Connect your repository
Connect GitHub and authorise the Openstead GitHub App for the repository. Signing in with GitHub and granting deployment access are separate actions. You can grant selected repositories instead of all repositories.
Select the repository and branch. For a monorepo, set Root Directory to the application directory, such as apps/api. Openstead checks the selected source and proposes supported runtime and build settings.
If the repository does not appear, use Configure repo access, check the correct GitHub personal or organisation account, and grant the Openstead installation access. An organisation owner may need to approve the installation. See GitHub deployments.
4. Review the configuration
| Setting | What to check |
|---|---|
| Name | A unique, recognisable name for this service |
| Project and environment | The intended application group and network boundary |
| Root directory | The directory containing this application's manifest |
| Build command | The command that installs or compiles the application |
| Start command | The long-running production command for a web service |
| Port | The port your application actually listens on |
| Publish directory | The generated output directory for a static site |
| Environment variables | Required configuration and secrets |
| Instance type | Resources and price appropriate to the application |
Web applications must listen on 0.0.0.0, not only localhost. Use the configured port consistently. Run a production server, rather than a development watcher.
Add credentials in Environment variables. Browser-exposed frontend variables must never contain database passwords or Openstead API keys.
If the app needs a managed database, create it in this environment first and add a connection reference. Wait for the database to be running before deploying the application that depends on it.
5. Deploy
Review the selected plan. Free services do not require checkout. For paid compute, review and confirm the service-month quote, complete hosted checkout, and return to Openstead. Payment confirmation and application deployment are separate stages.
Start the deployment and follow the build logs. A successful build produces an application release; Openstead then starts the service and checks its health. The page shows whether the deployment is queued, building, deploying, live, or failed.
6. Verify the live application
Open the service's public URL after the deployment is live. Test more than the homepage: check authentication, a database-backed page, static assets, and an upload if your application supports them.
Use Logs to inspect application output. A running container can still return an application error if a migration, secret, or framework setting is missing. See the matching framework guide before running migrations or changing production configuration.
Next steps
- Connect your own domain.
- Create a database backup before a schema change.
- Enable the deployment behaviour you want for future Git pushes.
- Invite your team and enable two-factor authentication.
If deployment fails, inspect the first meaningful error in the build or application logs and follow Troubleshooting. Repeatedly clicking Deploy without correcting the cause usually produces the same result.