Building the complete release experience
How the beta works.
A stable web foundation. A release journey we can prove together.
We're inviting you to build a real web app with Amber. This beta actively tests our release contract: the promise that your code, dependencies, installation, updates, documentation, tutorials, and agent guidance work together.
Beta.5 already has coordinated proof for the framework, CLI, a generated database-backed web app, packages, guides, and public website. Pioneers help us exercise that journey with more real apps and close the remaining gaps.
The beta exercises the release journey. Website policy is published; required GitHub enforcement and the full ecosystem bundle are separate work.
Bring one app. Follow the journey.
Contributions require a coding assistant. You own the idea, review the evidence, and accept the result. Your assistant helps inspect the repository, build, reproduce behavior, and prepare the proposal.
- Install and build. Follow the published installation guide. Create a page and a record, edit it, and restart to check your data.
- Learn and make a change. Use the Pet Tracker tutorial and the read-only docs MCP. Minecart's available Shards Alpha tools supply dependency guides and agent context.
- Try the next release. When an applicable beta arrives, follow its upgrade instructions. Check that your app, data, docs, and edited agent context still agree. Report the versions and what happened.
- Bring a report to GitHub. Ask your assistant to inspect existing issues and prepare the versions, expected/actual behavior and reproduction evidence. Review it, then open an issue proposal. Maintainers connect it to a decision and any resulting change.
Join Amber's Discord for community conversation. Contributions return to a GitHub issue before a linked PR. We're recruiting web-app builders first. Mobile is the next expedition.
A few patterns you can choose with confidence.
Need an idea? Try an organization client portal, an inventory tracker, or a service request desk. Choose a starting problem and add it to your agent's request.
We're building business templates that come with a working example, migration guidance, and a published tested operating range. You should be able to choose a pattern and deployment profile before building, then use the supplied checks to see how your app fits.
Each recommendation needs a measured workload, data size, database, hardware, release identity and performance targets. Current app invitations have unmeasured capacity. Existing core research keeps its own scope. Read the template promise, or start with the tenancy guide and article plan.
What's ready to build on?
The supported web path is stable and release-gated: routing, ECR pages and forms, Grant records, migrations, jobs, WebSockets, and manifest-backed local assets. The support matrix names tested platforms and the separate preview boundaries for native apps, generated authentication/API resources, and Gemma.
The component trail and FrontLoader/Asset Pipeline work belong on the roadmap alongside the framework's performance research. Published manifest comparisons show the framework core moving from 16 direct runtime shard dependencies in 1.5.0 to zero in beta.5. The separate CLI and your app have their own dependencies. Explore the scoped measurements and component progress.
Performance improvements should come with workloads, before/after results, and evidence. Local performance-budget tooling is exercised; its public CLI release and mandatory release-CI integration remain open. This is part of the contract we're completing.
How we decide and release.
- Issue proposal
- Accepted scope
- Reviewed PR
- Verified release
- App feedback
You bring the need.
Every contribution starts with an issue proposal. Describe the outcome and versions; link related work. Build your app, return evidence, and decide what success means for it.
Maintainers review the path.
Maintainers agree on scope before a linked PR, review behavior and evidence, and connect the change to its guides and release.
The owner approves.
Seth owns the current project direction. The website's existing gates require his approval of rendered release proof. Each release needs an accountable steward and a recorded approval.
The evidence travels.
Exact versions, verified hashes, behavior, docs, tutorials, agent guidance, and relevant performance results stay linked to the release. Short notes point readers to the detailed resources.
The issue-first direction is adopted here. The same public policy, named role roster, and required GitHub checks still need installation. Read the governance guide for the current authority and proposed decision record.
What we're completing.
The next step is to carry one web feature and an existing app through the entire contract: proposal, implementation, versioned guidance, fresh install, update, agent-assisted change, budgets, approval, publication, and recovery.
- One verified release identity for the roadmap, website, library docs, docs MCP, agent catalogs, packages, and tool updates.
- Package versions and verified dependency/compiler-build provenance for every included library and tool.
- Runnable tutorials and intended-use guidance that follow the selected release.
- Required performance scenarios and exercised upgrade/recovery checks.
- Shared public governance, proposal intake, and evidence-based status updates.
The existing beta.5 receipts establish the working baseline. Automatic bundle publication and ecosystem-wide enforcement are still being built. Read the complete coverage review.
Your app can lead the next pioneer.
We're proposing a showcase for apps people build with Amber. Ask your coding assistant to help prepare your story and public project link, then share it in a GitHub issue. Maintainers confirm your permission and agreed credit in that issue before publication.