openstead
Changelog

Documentation, lighter pages, and clearer service operations

Dedicated docs, lighter website loading, connected support, and more accurate service status and diagnostics.

Suggest a change

This week's updates make Openstead easier to learn, navigate, and operate. This entry covers the September 28–October 4 reporting week and completes the update first published during that week.

Added

  • A dedicated documentation site. The initial release brings together 109 pages covering services, frameworks, private databases, networking, Blueprints, developer tools, workspaces, and billing. Start with your first deployment, choose a service type, or jump into a framework guide such as Laravel, Django, or Next.js.

  • An API reference for all 28 core operations. Each endpoint page includes its method, request fields, responses, and code examples. The interactive playground sends requests to the real Openstead API, with a workspace key for authenticated operations. Review the operation before sending a request that changes a resource.

  • Search and Markdown access. Search across guides and reference pages, use the page outline to move through longer articles, or copy a page as Markdown. The documentation index and complete Markdown export make the same material available to developer tools, including useful endpoint details and referenced schemas.

  • Platform status and incident guidance. Open System status from the documentation or console to see component availability and incident updates without signing in. The status guide explains what each check covers and how to distinguish a platform issue from a problem with one application.

  • A direct way to contact support. Send a request through the contact form instead of opening an email app. The form confirms a reference after your request is saved, which you can use when following up. Support chat is also available on the website and regular documentation pages.

  • Optional analytics controls. On the website and documentation, choose whether to allow analytics and revisit that decision from the footer. Your choice is shared across those openstead.tech sites. Browsers that send Global Privacy Control keep analytics disabled. Read the privacy policy.

Improved

  • Documentation where you need it. The marketing website and console help now link to the hosted documentation. Product pages lead to relevant guides, and existing documentation links redirect to the new site.
  • Openstead addresses across the product. Website, dashboard, documentation, and status links now use openstead.tech addresses. Navigation between the website and console keeps those destinations consistent.
  • Website navigation for signed-in users. After your console session is confirmed, the marketing header shows Dashboard in place of Log in and Sign up. Session checks happen in the background without delaying the page.
  • Lighter website loading. The homepage keeps its headline and illustrations visible as the page becomes interactive, downloads smaller fonts and fewer repeated logos, and defers rendering sections below the viewport. The existing navigation and automatic animations remain available on desktop and mobile.
  • Lean initial guide loading. Regular documentation pages no longer download the interactive API playground. API reference pages also keep support-chat and optional analytics scripts away from the playground where you enter an API key. Explore the API reference.
  • Clearer service and pricing information. Website content now explains the services offered in the console, resource pricing, and monthly renewal behavior. USD checkout and illustrative NGN budget estimates are distinguished, with persistent-storage costs included in the calculator.
  • Project and environment overviews. The workspace overview shows project cards and ungrouped services. Inside a project, each environment has its own service list and current status, making it easier to find a service without relying on a previous deployment result. Organise projects and environments.
  • Details from the running release. Repository-deployed services show the repository, branch, and commit actually running. Internal addresses use the activated port where applicable. A later failed build or an unapplied configuration change no longer replaces those details. Custom domains stay prominent, with additional addresses in the dropdown; copying a compact service ID still copies the full identifier. Manage web services.
  • More useful logs, metrics, and events. Search, wrap, expand, and download displayed log lines. Metrics retain their actual sample timestamps and visible gaps. Runtime events have date, type, and text filters, with links to the relevant debugging views and recorded failure reasons when available. Use logs and metrics or troubleshoot a deployment.
  • Custom-domain management. Search and sort the domains attached to a service, then check DNS verification and HTTPS certificate status separately. Each domain provides its DNS records and a way to check again when setup needs attention. Connect a custom domain.
  • Slack notifications with service context. Service alerts name the affected service and link to it in the correct workspace; deployment alerts link to the specific deployment. This makes a shared channel easier to use when several services send notifications. Set up notifications.
  • Consistent platform failure pages. Missing-page and runtime failures across the website and console use a shared presentation. Hosted gateway failures show a clear status and next step; when a request reference is available, it can help support identify that failure. Your application's own responses and custom error pages remain under your control. Troubleshoot a deployment.

Fixed

  • Status follows the current runtime. A previous successful deployment no longer keeps an unavailable application marked Live. Recent runtime observations determine availability and recovery, while deployment history continues to describe each release's outcome. Investigate an unavailable service.
  • Service deletion tracks cleanup to completion. Existing service detail pages retain deletion progress while runtime resources are being cleaned up, even after the service leaves the project list. A removed service cannot be resumed as though it were still active. Delete a service through the API.
  • Protected configuration keeps its access rules. Owner and admin restrictions follow configuration inherited through shared environment groups, database references, and previews. Removing a link does not lower those restrictions for services that may still contain the protected credentials. Revealed configuration is also cleared when access is lost or the workspace changes. Protect an environment.
  • Static-site platform fallbacks. Corrected the routing used to serve platform error responses for static deployments, while retaining custom 404.html pages and SPA routing behavior.
  • Usable API examples from the first render. Reference examples use the Openstead API URL and clearly marked credential placeholders. Markdown copies include endpoint parameters, request and response information, rather than an empty component placeholder.
Need a hand? Contact Openstead support.

On this page