From repository to running application

Openstead started with a straightforward idea: bring your application code and configuration, and let us operate the infrastructure. Product planning began on September 23. The releases collected in this first weekly update followed on September 24–26.

AddedCopy Anchor Link

• Deploy from GitHub or a container image. Connect a repository, let Openstead detect the application, review the build settings, and deploy a web service, static site, private service, background worker, or cron job. Dockerfile and image-based deployments support applications that need their own build or runtime setup.

• Managed databases alongside your applications. PostgreSQL, MySQL 8.4, and Redis-compatible Key Value connect to services over Openstead's private network. PostgreSQL and MySQL include backup and separate-database restoration workflows.

• MySQL Free. Each workspace can run one free MySQL database with 768 MiB of memory, 2 GiB of persistent storage, up to 25 connections, and up to seven days of backups. It does not require a card or expire automatically. Explore MySQL plans.

• phpMyAdmin from the console. Open phpMyAdmin from an eligible MySQL service using your Openstead session. The manager is limited to that database, while the MySQL connection itself remains private.

• Projects, environments, and application configuration. Group services into projects and environments, manage encrypted variables and secret files, and configure private service connections, persistent disks, and custom domains with HTTPS.

• Release and runtime controls. Follow deployment stages, inspect logs and metrics, configure health checks, and roll back to a retained release. Restart, suspend, and resume services from the console. Paid application instances also support the shell and one-off commands.

• Blueprints with GitHub synchronization. Define related services in a Blueprint YAML file and create their project together. Repository synchronization applies configuration changes from the selected branch, with an option to deploy changed services. Removed YAML entries retain their existing services until you explicitly remove them. Use Blueprints.

• A documented core API and developer tools. The REST API includes an OpenAPI contract, bounded collection pagination, structured errors, and idempotent writes. Python and TypeScript clients add typed responses, iterators, and deployment polling; their guides explain repository access and installation. The CLI and MCP server provide workspace-scoped access from terminals and compatible assistants.

• Connections to your existing tools. Deploy private images with workspace registry credentials, receive signed webhook events, send Slack or Discord notifications, and forward application logs or metrics to your own collector.

• Monthly service checkout and renewal invoices. Paid applications and databases use hosted checkout for monthly service terms. Renewal invoices are issued two days before expiry. An unpaid term has a three-day grace period before compute pauses, with database data and disks retained.

ImprovedCopy Anchor Link

• Less repeated deployment work. Build preparation now warms the tools used by the actual build, service-specific caches retain reusable layers, and matching unchanged release artifacts can be reused. Eligible static applications publish their built files directly. How builds work.
• Clearer custom-domain progress. The domain dialog checks verification automatically while open and shows DNS verification and HTTPS readiness separately. Connect a domain.
• A more direct sign-in experience. Social sign-in buttons show the last successfully used provider. Full-page preloaders were removed from authentication and dashboard interfaces so the page structure can appear while data loads.

FixedCopy Anchor Link

• PostgreSQL persistence across replacement. Corrected version-specific data mounts and added storage-identity checks. Replacement and backup-restoration checks confirmed data remains on the intended persistent volume. Database storage and recovery.
• Repository access for GitHub organizations. Configuration links now use the correct organization installation page instead of a personal-account URL that can return 404. Manage GitHub access.
• Repeated environment keys during service creation. Environment-file imports keep the last value for each key. Duplicate keys entered directly receive a specific validation message instead of the misleading resource-name conflict. Environment variables.
• Cancellation and intentional stops. Queued cancellations finish without being reported as operator failures, and intentional service stops no longer trigger the same outage alerts as an unexpected failure.