Start with detected settings
Repository analysis suggests the runtime, build command, start command and application structure. Review and edit the result before deployment.
Deployments
Every change.
A clear path to live.
Connect your repository, review the detected application settings and follow your code through build and release. Openstead keeps each deployment tied to the source and configuration that produced it.
Your code. Infrastructure included.
A small change. A new possibility.main · 8c29b4f · your latest commit
DetectPython application
01BuildCreate application image
02CheckVerify /health
03ReleaseReady for requests
04 Every stage belongs to the same deployment.
DetectReview suggested application settings
BuildFollow output as the build runs
ReleaseTrack the deployed application
DEPLOYMENTS ON OPENSTEAD
A deployment should be something you can follow.
Keep the important context with the release. See the commit, the commands and the output that tell you how your application became a running service.
Work from your connected branch
Authorize the GitHub repositories you choose. Enable automatic deployments when they suit your workflow, or trigger a deployment yourself.
Keep failure details close
Follow build and deployment output from the release page. A failed build stays in history so you can inspect the cause and deploy a correction.
MADE FOR YOUR STACK
Automatic when useful. Explicit when needed.
Detection gives you a starting point, while editable settings keep unusual project structures and dependencies within reach. The configuration remains part of your service.
- Set an application root for a repository with multiple projects.
- Use your own Dockerfile, build command or start command.
- Paid instances support pre-deploy commands for release tasks.
An application releaseopenstead / configuration
DEPLOYMENT WORKFLOWSource your-team / application
Branch main
App root apps/api
01 Prepare source and build configuration
02 Build application artifact
03 Run configured release steps
04 Start and check the application
05 Record the live deploymentThe stages depend on the service type. Database migrations should be compatible with the application versions you deploy.
PUT IT TO WORK
Built for the work
your application does.
Single applications
Move from repository selection to a running service with commands suited to your framework.
Monorepos
Choose an application root so each service builds the component it owns.
Custom runtimes
Use a Dockerfile or deploy a container image when your build needs a more explicit environment.
HOW IT WORKS
From a selected repository to the running release.
Review the setup
Select the repository, branch and application directory. Confirm build settings and add the variables the service requires.
Follow the build
Openstead prepares the application artifact. Use the deployment log to follow dependencies, build commands and startup checks.
Observe the release
Open the running service, inspect runtime output and check resource usage. Deployment history keeps the source of each release visible.
Does detection happen after repository selection?
Yes. Repository analysis suggests application settings during service setup. Review the application directory, runtime and commands before confirming the deployment.
Can I override the detected settings?
Yes. Build and start commands are editable. You can choose an application root or use a Dockerfile for custom dependencies and runtime requirements.
Can I deploy without a Git repository?
Services that run containers can use a container image as their source. Configure the image and any required registry credentials in the console.
Does an application rollback reverse database changes?
No. Application releases and database changes have different lifecycles. Use compatible schema migrations and a separate database recovery plan.
MAKE YOUR NEXT MOVE
Make shipping part of your day.
Your code. Infrastructure included.