Release notes · synchronized from GitHub

Know what shipped.
And what beta means.

GitHub Releases remains the source of truth. This page turns those records into a dated, readable map of the stable framework, V2 web beta, and standalone CLI.

Last synchronized November 1, 2026 at 23:40 UTC Automatic check every hour · All project repositories

Current choices

Three versions.
Three different jobs.

The framework runtime and the CLI now have independent releases. Pick the framework line first; use the current CLI when creating a new V2 application.

Stable framework

v1.5.0

The conservative Amber 1.x line for existing applications, with current Crystal compatibility and maintenance corrections.

Read the official GitHub release →
Standalone CLI

v2.0.8

The current application generator and development command. Its release cycle is independent from the framework dependency in your app.

Read the official GitHub release →

The word “beta,” unpacked

The web path is coherent.
The frontier stays named.

V2 is tagged as a prerelease while real applications test it in public. Routes, controllers, ECR views, configuration, schemas, WebSockets, jobs, and the clean web template form the web-framework core being release-gated.

Preview does not spread by association. Grant persistence and the static Asset Pipeline are part of the tested web path. Attachments, generated authentication and APIs, and native applications keep their own status.

V1 applications are not expected to be rewritten. Many ECR applications can begin—and some can finish—with the Amber version change in shard.yml. The migration guide identifies the bounded exceptions.

See the smallest safe upgrade path

Synchronized history

Notes from the repositories.

Every entry links to its authoritative GitHub record. Expand an item here for the published release body.

Amber Framework

v2.0.0-beta.7Amber 2.0.0-beta.7

Amber 2.0.0-beta.7

Amber 2.0.0-beta.7 makes the fixes that AgentC applications carried on a fork part of Amber itself, so those applications can depend on an official release again. It also routes .md paths to the routes that declare them, bounds request parameter parsing, and reads credentials from a systemd-style credentials directory.

What changed

  • A path ending in an extension reaches the route that declares it (#1431). Beta.6 added .md to the response extensions it removes before matching, so /projects/7/insights/overview.md was matched as /projects/7/insights/overview and could land on a later get "/*" catch-all. A route that spells the extension in its own path, such as get "/projects/:project_id/insights/overview.md" or get "/guides/setup(.md)", now answers first. A path that no route declares still has its extension removed, so /users/1.json matches /users/:id. A route's request constraint is asked once per request, and a constraint that reads request.params sees that route's parameters.

  • The request body stays readable after Amber parses a form (#1429). A controller behind the CSRF pipe can read request.body again; the bytes are handed back from the bounded parse. A multipart body is restored up to params.max_multipart_restore_bytes (8 MiB by default, 0 turns it off) when its Content-Length is declared and within that limit and params.max_multipart_body_bytes; any other multipart body stays drained.

  • Upload tempfiles are deleted when the request finishes (#1429). To keep an upload, call Amber::Router::File#move_to(path) during the action, or #retain! to keep the tempfile at #path and delete it yourself, for example after a background job.

  • Custom config sections load as raw YAML (#1430). Amber no longer deserializes a custom section through every YAML::Serializable type, so an application whose Grant models have UUID columns compiles with custom config again. AppConfig#custom reads a section as the requested type or returns its registered default; an unregistered key raises Amber::Exceptions::ConfigurationError.

  • Settings load at first use (#1424). require "amber" no longer reads settings, so a section registered in config/initializers reads its YAML value, and config/application.cr can still set Amber.path and Amber.env. Amber colors its own log lines from logging.colorize and leaves the global Colorize.enabled flag alone.

  • Request parameters are bounded (#1419). Counts, nesting depth, key and value sizes, body sizes, array indices and padding, multipart parts, uploads and WebSocket messages each have a limit in the new params: section of config/environments/<env>.yml (or AMBER_PARAMS_<KEY>). An HTTP request beyond a limit is answered with 400 Bad Request; a WebSocket message over max_websocket_message_bytes (2 MiB) closes the connection with code 1009. The defaults and every limit are listed in CHANGELOG.md.

  • Credentials directory (#1423). Amber::Configuration.register_credentials reads a systemd-style credentials directory, one file per credential, into a typed section. The application passes the directory, usually from CREDENTIALS_DIRECTORY, before settings load:

    Crystal
    if credentials_directory = ENV["CREDENTIALS_DIRECTORY"]?
      Amber::Configuration.register_credentials(:credentials, AppCredentials, credentials_directory)
    else
      Amber::Configuration.register(:credentials, AppCredentials)
    end
    

    AMBER_{SECTION}_{KEY} overrides now reach registered custom sections.

  • A GREEN build (#1421): no compiler warnings. The ecosystem agent context now names Micrate, Gemma and Mica (#1417).

Fork fixes now in Amber

Fix Fork commit Upstream
Restore the request body after form parsing 8c71a57c #1429
Delete upload tempfiles at request teardown 0fbd8eba #1429
Read custom config as raw YAML bc0d62c6 #1430
Answer 404 before checking a route's constraint when no route matches valid_route? guard already in Amber (7224cb57)

An application can drop its fork pin and depend on this release.

Upgrade

Change the version:

YAML
dependencies:
  amber:
    github: amberframework/amber
    version: 2.0.0-beta.7

Then check three things:

  • Uploads you keep. An action that keeps an uploaded file past the request calls #move_to or #retain!; otherwise the tempfile is gone when the response is sent.
  • Large requests. A form, JSON body or upload larger than the defaults (8 MiB form and document bodies, 64 MiB files, 128 MiB multipart bodies) needs its limit raised in params:.
  • Custom config readers. Code that called Amber::Configuration.load_custom_from_yaml reads sections with Amber.settings.custom(:name, Type) instead.

Beta.6 also stopped sending Keep-Alive response headers (deb16f8e); a spec that expects them needs updating.

Release

The tag is v2.0.0-beta.7. The GitHub release for the tag states the tagged commit hash, its tree hash, and the sha256 of the source tarball attached to the release (scripts/release_checksums.sh v2.0.0-beta.7 produces all three). A file cannot carry its own tarball's hash, so they live in the release.

Verify this release

Example
Commit: 21deeec92b9253e9fc7252f994fc3465da0ffd4f
Tree: d7af4f30415f80e633c49c2d1ff0c32ac6ac7c1a
Tarball: amber-2.0.0-beta.7.tar.gz (git archive --format=tar.gz --prefix=amber-2.0.0-beta.7/ 21deeec92b9253e9fc7252f994fc3465da0ffd4f)
Tarball sha256: 988a556bd1bf85b6b7e2a24cbe80559b558694ed1ec1333fa5164f7059a0bddb
Open the source release on GitHub →
v2.0.0-beta.6Amber v2.0.0-beta.6

Amber 2.0.0-beta.6

Amber 2.0.0-beta.6 takes libxml2 out of every Amber V2 application. Until this release, every V2 app linked libxml2, and with it liblzma, because the schema layer could parse XML request bodies. XML is now opt-in, and the opt-in is Mica, a pure-Crystal XML parser, so an application that accepts XML still links no XML library.

What changed

  • XML request bodies are opt-in (#1414). The libxml2-backed Amber::Schema::Parser::XMLParser is removed. A request sent as application/xml, text/xml or any +xml type is answered with 415 Unsupported Media Type unless the application registers a parser.
  • ParserRegistry.register_body_parser (#1414) lets an application add a request body format with one call at boot. A parser that raises answers the request with 400 invalid_request_body.
  • CI is pinned (#1420): Crystal 1.22.1 tarballs checked by sha256, GitHub Actions by full commit SHA, the CircleCI image by digest, dependencies from a committed shard.lock with --frozen, and a second job that builds crystal-alpha from an exact commit and runs the suite on it.
  • Specs pass on Crystal 1.22 (#1418), which rejects the empty request resource and the malformed multipart fixture some specs used.

Turning XML back on with Mica

Add Mica v0.1.0 (release, commit 6a4866e) to shard.yml:

YAML
dependencies:
  mica:
    github: amberframework/mica
    version: 0.1.0

Register it in config/initializers/request_body_parsers.cr, and make sure config/application.cr loads the initializers (require "./initializers/*"; applications generated by Amber CLI 2.0.6 load config/*.cr only):

Crystal
require "mica/xml/fields"

{"application/xml", "text/xml"}.each do |media_type|
  Amber::Schema::Parser::ParserRegistry.register_body_parser(media_type) do |body|
    Mica::XML::Fields.read(body)
  end
end

List the media types in the action's schema:

Crystal
class CreateSubscriberSchema < Amber::Schema::Definition
  content_type "application/json", "application/xml", "text/xml"
  field :email_address, String, required: true, format: "email"
end

Mica::XML::Fields.read turns an XML body into the same fields a JSON object gives, so <subscriber><email_address>[email protected]</email_address></subscriber> and {"email_address": "[email protected]"} validate the same way. It refuses a DTD at the <!DOCTYPE (so no external entity, entity expansion or attribute default reaches the fields), caps bodies at 1 MiB and nesting at 64 levels, and charges every step of the read to a work budget.

Measured

A sample Amber V2 + Grant + PostgreSQL application (examples/zero_link_app), built as a static musl binary with --static --release --no-debug in the official Crystal 1.22.1 Alpine image (pinned by digest, linux/arm64), from an empty compiler cache, twice per variant. Before is Amber 2.0.0-beta.5 with its built-in XML parser; after is this release with Mica registered. Evidence, scripts and raw logs: examples/zero_link_app/evidence/.

before (beta.5) after (#1414 + Mica)
libxml2 objects linked 108 0
liblzma objects linked 68 0
zlib objects linked 15 11
static archives used 12 10
defined xml* / lzma_* / zlib symbols 2,420 / 109 / 46 0 / 0 / 46
-l flags adds -lxml2 -llzma neither
binary size 29,600,248 bytes 26,103,720 bytes (11.8% smaller)
binary size after strip 11,169,352 bytes 10,381,728 bytes (7.1% smaller)
dynamic libraries needed (readelf -d) none (static PIE) none (static PIE)
clean release build, 2 runs 109.0 s, 119.0 s 93.0 s, 81.0 s

Both binaries are static: readelf -d lists no NEEDED entries and there is no program interpreter. zlib stays linked because Grant (grant/encryption/compression.cr) and asset_pipeline (asset_pipeline/static_assets.cr) use the standard library's Compress; Amber itself does not. The remaining archives are libc, libcrypto, libssl, libgc, libgmp, libpcre2-8, libyaml, libz and the compiler's libgcc and libgcc_eh.

Build times are reported, not claimed: in this Docker VM (4 CPUs) the same beta.5 build ranged from 83 to 133 seconds across five clean builds, so two runs per variant cannot separate a compile-time change from noise.

The after binary, run in an Alpine image with no libxml2 installed, answered JSON, application/xml and text/xml bodies with 201 and wrote 3 rows; an invalid email with 422; malformed XML with 400 and its position; an external entity and a billion-laughs body with 400 at the <!DOCTYPE (byte 0); and application/xhtml+xml with 415 (results/after.smoke.txt).

Measured on 2026-11-01 with Amber b9d246ba and Mica 2a4ab10, now c11b6cc after a history rewrite that left file contents identical. The sample now pins Mica v0.1.0 (6a4866e; see ../shard.lock).

Upgrade

An application that accepted XML bodies through the schema API either moves those endpoints to JSON or registers Mica as above. Everything else upgrades by changing the version:

YAML
dependencies:
  amber:
    github: amberframework/amber
    version: 2.0.0-beta.6

Release

The tag is v2.0.0-beta.6. The GitHub release for the tag states the tagged commit hash, its tree hash, and the sha256 of the source tarball attached to the release (scripts/release_checksums.sh v2.0.0-beta.6 produces all three). A file cannot carry its own tarball's hash, so they live in the release.

Verify this release

Example
Commit: a61cb0e436d3cffbc1feb381187b03c25e45f743
Tree: aef5979f5a1beec1c825a05ef83d8942583b5e38
Tarball: amber-2.0.0-beta.6.tar.gz (git archive --format=tar.gz --prefix=amber-2.0.0-beta.6/ a61cb0e436d3cffbc1feb381187b03c25e45f743)
Tarball sha256: ec0e01f0da912fbc618782ff7b8e610d3414a4c26a6be8b6e6b335aeba388d24
Open the source release on GitHub →
v2.0.0-beta.5Amber 2.0.0-beta.5

Amber 2.0.0-beta.5

Amber 2.0.0-beta.5 turns the V2 schema API into a contract the framework actually enforces. A controller declaration now owns request parsing, validation, typed access, response validation, content negotiation, and OpenAPI 3.1 output. The release also brings the optimized router and request path onto the V2 release line.

Upgrade compatibility comes first

The existing params.validation API still compiles and runs. It is deprecated so new work can use executable controller schemas, but upgrading to beta.5 does not require rewriting every controller. Applications can update Amber, run their existing tests, and then migrate one action at a time.

Amber does not plan to remove the deprecated validator before a later V2 minor such as 2.5. The exact removal release will be announced separately.

Executable request and response contracts

  • schema :action, SchemaClass enforces the declared request before the action runs.
  • validated_as(SchemaClass) exposes request-local typed values without constructing and validating a second schema object.
  • Request fields can come from bodies, paths, query strings, headers, and cookies.
  • response_schema verifies the declared status, content type, and response shape before delivery.
  • OpenAPI 3.1 operations are generated from the same contracts the application executes.
  • Server-rendered controllers can override the schema-failure hook to return an ECR form with field errors and the correct 400, 415, or 422 status.

JSON, CBOR, and authenticated COSE

Amber now supports JSON, XML, URL-encoded forms, multipart forms, and bounded CBOR request parsing. COSE Encrypt0 adds authenticated ChaCha20-Poly1305 encryption in both directions: Amber decrypts and authenticates the inbound request, applies its schema, and can authenticate and encrypt the response with a fresh nonce.

The request boundary fails explicitly for malformed documents, unsupported media, invalid values, unacceptable response formats, invalid declared responses, and temporarily unavailable encryption configuration.

Measured performance

The release candidate was tested on a DigitalOcean Basic one-shared-vCPU, 512-MB-class target with a separate load generator, 16 keep-alive connections, and seven rotating 15-second repetitions per scenario:

Complete HTTP request path Median requests/second
Generic JSON decode 20,728
Schema-validated JSON 19,488
Schema-validated CBOR 21,742
Authenticated COSE request and response 14,443

All 7,974,608 retained requests returned HTTP 200. This is a synthetic in-memory acknowledgement workload without a database, TLS termination, external services, or HTML rendering. It measures framework, codec, and schema cost under constrained hardware; it is not a capacity promise for an arbitrary production application.

See benchmarks/DIGITALOCEAN_SCHEMA_CONTRACT_ROUND27.md for the complete method, ranges, before-and-after comparison, and evidence paths.

Start a fresh web application

Amber CLI 2.0.6 is the coordinated generator release for this beta:

Terminal
brew install amberframework/amber_cli/amber_cli
amber new pet_tracker --type web
cd pet_tracker
shards install
amber assets check
amber generate scaffold Pet name:string:required species:string:required adopted:bool
amber database migrate
crystal spec
amber watch

The generated application uses ECR, Grant, SQLite, Micrate, local front-end assets, executable HTML form schemas, and Amber 2.0.0-beta.5.

See the beta installation guide, migration guide, and schema guide.

Open the source release on GitHub →
v2.0.0-beta.4Amber 2.0.0-beta.4

Amber 2.0.0-beta.4 connects the V2 web runtime to the deterministic asset compiler and closes the fresh-application path across macOS, Linux, Linux ARM64, and Windows CI.

The beta label applies to the Amber 2.0 release train. The supported surface is the ECR web application created by Amber CLI 2.0.5; native applications and authentication generators remain explicitly marked preview features.

What ships

  • Manifest-backed asset_path, stylesheet, JavaScript/import-map, image, and favicon helpers with Subresource Integrity metadata.
  • Production manifest caching and development reload behavior.
  • Immutable cache headers plus correct media type and content-length metadata for fingerprinted assets.
  • Precompressed gzip negotiation, byte ranges, conditional requests, HEAD, and safe non-fingerprinted fallback behavior.
  • AMBER_DATABASE_URL configuration with DATABASE_URL fallback for generated Grant applications.
  • Windows-safe server startup: Amber no longer invokes Crystal's unimplemented Windows signal-trap API.
  • Updated installation, migration, asset-helper, configuration, and release-contract documentation with exact file locations.

Supported fresh web-app contract

The release-gated path covers generation, dependency installation, asset compilation and verification, Grant/SQLite/Micrate migrations, resource scaffolds, specs, production compilation, server startup, the generated homepage, and live database CRUD.

  • macOS Apple Silicon: supported and release-gated.
  • Linux x86_64: supported and release-gated.
  • Linux ARM64: supported and release-gated.
  • Windows x86_64: the generated application path is release-gated in CI; build the CLI from source because a standalone Windows archive is not published yet.

Validation

  • 2,350 framework examples passed with no failures.
  • GitHub Actions passed on Linux and macOS; CircleCI passed.
  • The Windows generated-app gate compiles and runs this exact framework revision through Amber CLI CI.

Use Amber CLI 2.0.5 to create a new web application. See docs/beta-installation.md and docs/migration-guide.md in the repository for the reproducible install and upgrade procedures.

Full change: #1407

Open the source release on GitHub →
v2.0.0-beta.3Amber 2.0.0-beta.3

Amber 2.0.0-beta.3

Amber 2.0.0-beta.3 is the framework release for the database-backed web application that Amber CLI 2.0.4 generates by default. The supported path now includes Grant models, SQLite, Micrate migrations, and complete HTML resource scaffolds instead of stopping at a database-free homepage.

What changed

  • Schema controllers parse browser form bodies, including bodies already read by routing or CSRF protection.
  • Background-job workers can steal queued work without corrupting request activity accounting.
  • ECR view paths are normalized on Windows.
  • The HTML/JSON respond_with behavior is documented with executable examples.

Install and exercise persistence

Install Amber CLI 2.0.4, then generate and migrate a real resource:

Terminal
brew install amberframework/amber_cli/amber_cli
amber new pet_tracker --type web
cd pet_tracker
shards install
amber generate scaffold Pet name:string:required species:string:required adopted:bool
amber database migrate
crystal spec
amber watch

Open http://localhost:3000/pets. The generated model lives at src/models/pet.cr, its SQL migration is under db/migrations/, and its ECR form partial is src/views/pet/_form.ecr.

Amber CLI 2.0.4 ships release archives for Apple Silicon macOS, x86_64 Linux, and ARM64 Linux. Windows x86_64 generated web applications are compile-gated in CI; build the CLI from source on Windows for this beta.

See the beta installation guide and V1 to V2 migration guide.

Please report framework issues at https://github.com/amberframework/amber/issues and CLI/template/install issues at https://github.com/amberframework/amber_cli/issues.

Open the source release on GitHub →
v1.5.0v1.5.0 — Crystal 1.21 support

Amber 1.5.0 — Crystal 1.21 support

Crystal 1.21 enables multithreading by default, which made Process.fork a compile-time error — and broke compilation of every Amber app on Crystal 1.21.0+ (Error: Process fork is unsupported with multithreaded mode). This release restores compatibility and ships the security and performance work that had been waiting in review.

Compatibility

  • Amber::Cluster.fork no longer uses Process.fork (#1399) — cluster workers are spawned with Process.new (same mechanism as v2). process_count / master-worker semantics unchanged. Verified: framework specs, amber new → build → serve, and cluster mode with 2 workers, on Crystal 1.20.3 and 1.21.0.
  • ameba pinned to 1.7.0-dev in framework dev-dependencies and the generated app template (#1399, supersedes #1394 — thanks @botantony). ameba ≤ 1.6.4 fails to build on Crystal 1.21, which broke shards install for new apps.
  • New COMPATIBILITY.md documents which Crystal versions build which Amber releases.
  • Declared Crystal requirement is now >= 1.20.0, < 2.0 (previously >= 1.0.0, which overstated reality).

Security (thanks @renich)

  • XSS: exception messages are HTML-escaped in the default error response (#1385).
  • Command injection: amber encrypt no longer passes the editor command through a shell (#1388).
  • DoS hardening: MessageVerifier / MessageEncryptor reject malformed payloads with typed exceptions instead of raising IndexError (#1386).
  • SecureHeaders pipe (#1390): new apps get X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, and Referrer-Policy out of the box, plugged above the Error pipe so 404/403 responses keep their headers; HSTS is opt-in (SecureHeaders.new(hsts: true)).

Performance

  • Router content-extension matching uses string ops + set lookup instead of regex alternation (#1387, #1391, thanks @renich).

CI / contributor experience

  • CircleCI (broken at the project level) replaced with GitHub Actions: spec matrix on Crystal 1.20.3 + latest, Linux + macOS.
  • Contributor review rubric, PR template, and local dev hooks (#1393).

Upgrade notes

  • If your app pins amber to 1.4.1 exactly (the default for apps generated by older CLIs), change it to ~> 1.5.0 in shard.yml to build on Crystal 1.21.
  • Existing apps do not get SecureHeaders automatically — it's wired in the new-app template. Add plug Amber::Pipe::SecureHeaders.new above plug Amber::Pipe::Error.new in your config/routes.cr to adopt it.
Open the source release on GitHub →
v2.0.0-beta.2Amber 2.0.0-beta.2

Amber 2.0.0-beta.2

Amber 2.0.0-beta.2 supersedes beta.1 for new Amber CLI web applications. It keeps the same public beta surface and fixes application startup on Crystal 1.21's default multithreaded runtime.

Compatibility fix

  • Replaced the server cluster launcher's Process.fork reference with portable process spawning.
  • Release-gated on Apple Silicon macOS and x86_64 Linux with Crystal 1.21.
  • Fresh ECR web apps are tested through dependency installation, specs, core generators, build, server launch, homepage delivery, and static CSS.

Install and create a web app

Install Amber CLI 2.0.2 or newer:

Terminal
brew install amberframework/amber_cli/amber_cli
amber new my_app --type web
cd my_app
shards install
crystal spec
amber watch

The generated application pins amberframework/amber at 2.0.0-beta.2 and uses ECR. Database drivers, persistence, auth, Grant, Gemma, Asset Pipeline, and native application generation remain opt-in preview surfaces rather than part of the core beta release gate.

See the beta installation guide and V1 to V2 migration guide.

Please report framework issues at https://github.com/amberframework/amber/issues and CLI/template/install issues at https://github.com/amberframework/amber_cli/issues.

Open the source release on GitHub →
v2.0.0-beta.1Amber 2.0.0-beta.1 (superseded by beta.2)

Amber 2.0.0-beta.1

Amber V2's first public beta establishes a tested, documented path for creating an ECR web application with the standalone Amber CLI.

This is a prerelease. Expect breaking changes before Amber 2.0.0 and do not use it for production workloads that cannot tolerate them.

Install and create a web app

Install Amber CLI 2.0.2 or newer:

Terminal
brew install amberframework/amber_cli/amber_cli
amber new my_app --type web
cd my_app
crystal spec
amber watch

See the beta installation guide for direct archives, checksums, update/uninstall steps, and troubleshooting.

Release-gated surface

  • Apple Silicon macOS and x86_64 Linux
  • Homebrew and matching direct CLI archives
  • ECR web application generation
  • dependency installation, specs, application build, server start, homepage, and static CSS
  • framework core, routing, typed configuration, Schema API, jobs, mailer, WebSockets, adapters, and testing helpers

Major V2 changes

  • CLI and LSP extracted to amberframework/amber_cli
  • ECR is the only supported view engine; Kilt and Slang were removed
  • runtime shard dependencies removed from framework core
  • database drivers and ORM are explicit application choices
  • typed, sectioned YAML with environment-variable overrides
  • built-in jobs, mailer, Schema API, and adapter-backed infrastructure

Read the V1 to V2 migration guide before upgrading an existing application.

Preview surfaces

Persistence/auth/API-resource generators, Grant integration, Gemma attachments, the separate Asset Pipeline, and native app generation are not part of the core beta release gate. Intel macOS, Linux ARM64, and Windows do not have release-gated CLI archives in this beta.

Please report framework issues at https://github.com/amberframework/amber/issues and CLI/template/install issues at https://github.com/amberframework/amber_cli/issues.

Open the source release on GitHub →

Amber CLI

v2.0.8Amber CLI 2.0.8

Amber CLI 2.0.8 generates applications on Amber v2.0.0-beta.7.

  • New web and native applications pin Amber by commit: commit: 21deeec92b9253e9fc7252f994fc3465da0ffd4f # v2.0.0-beta.7.
  • amber new checks the lock minecart writes. Every dependency must carry exactly one git-tree checksum, and Amber must be locked at that commit with tree d7af4f30415f80e633c49c2d1ff0c32ac6ac7c1a. If either check fails, it stops and keeps the files.
  • Generated apps ignore .encryption_key and load config/initializers (#45).

Commit: f8b60728d7755c6c1b96cd728efb6882df48c6e2 (tree 389edc1b448bc6231b8b9f31b9f2ae85405e1e40)

Source archive: amber_cli-source-2.0.8.tar.gz sha256 ad0ca67fb7b99523890ada2eb6d6a51c93c0c3055cfcf95ae9c67a0912136ff2

Open the source release on GitHub →
v2.0.7Amber CLI 2.0.7

Amber CLI 2.0.7 helps coding agents such as Claude Code and Codex write Crystal that compiles the first time, in Amber V2 apps, plain Crystal apps, and Crystal shards.

Install or upgrade

Terminal
HOMEBREW_NO_AUTO_UPDATE=1 brew install amberframework/amber_cli/amber_cli
amber --version
amber-lsp --version

What's new

  • amber-lsp lookup 'Type.method' answers from your project's real code: its own source, every shard in lib/, and the Crystal standard library. It prints the signature, the resolved return type, where the method is defined, its doc comment, and notes from API cards. It falls back to stock crystal when crystal-alpha is not installed.
  • amber-lsp hint reads compiler output and prints the fix for known mistakes.
  • amber setup:agent connects Claude Code and Codex to amber-lsp in any Crystal project. It installs hooks that tell the agent to look methods up first, format each edited file, check Amber V2 rules in Amber apps, and build when the agent stops. Crystal edits are held back until amber-lsp is installed and checksum-verified.
  • amber doctor reports the same readiness checks, agent trust, and index freshness, with a fix for each failure.
  • amber-lsp --help documents every mode.
  • API cards: libraries ship notes and error hints in .amber-lsp/api/*.yml. Grant, Amber, asset_pipeline, micrate, and gemma now include cards, and the Crystal card is bundled.
  • Minecart 2025.11.25.8 is the pinned dependency manager.

In a 40-task evaluation, requiring lookup raised first-try compile rates from 85.0% to 97.5% (Sonnet) and from 62.5% to 82.5% (Haiku).

See the agent tooling guide.

Amber CLI v2.0.7

Release commit: faed4b205063a84650b00e2dc02f01793f373527

Archive SHA-256 values:

Archive SHA-256
amber_cli-source-2.0.7.tar.gz 6e90f3cdba3ed87cefbf7443ab93da627af314fac5960a4b9288ae80e31f591f
amber_cli-darwin-arm64.tar.gz: OK
amber_cli-darwin-arm64.tar.gz 0a9fb1227af6574c689eae3d2f4d83281cc3edfab3d40799079d470bb2c7ce61
amber_cli-linux-x86_64.tar.gz: OK
amber_cli-linux-x86_64.tar.gz 679b2a55b9b6ee22c73f644e41843eea2ae2ceb633ca72125620ae129133c4aa
amber_cli-linux-arm64.tar.gz: OK
amber_cli-linux-arm64.tar.gz 6b5aa8ad8b671c0f9df33850c452671925162aa794d83077684f60a0cfc8f9e4
Open the source release on GitHub →
v2.0.6Amber CLI 2.0.6

Amber CLI 2.0.6

Amber CLI 2.0.6 is the coordinated generator release for Amber 2.0.0-beta.5. Fresh web applications now use the framework's automatically enforced schema contracts instead of constructing and validating a second schema object inside each controller action.

Generate a complete web application

Terminal
amber new pet_tracker --type web
cd pet_tracker
shards install
amber assets check
amber generate scaffold Pet name:string:required species:string:required adopted:bool
amber database migrate
crystal spec
amber watch

The generated project pins canonical Amber 2.0.0-beta.5, uses ECR, Grant, SQLite, Micrate, local front-end assets, and a manifest-backed asset pipeline.

What changed

  • Resource scaffolds bind PetSchema automatically to create and update and read typed request-local values with validated_as(PetSchema).
  • HTML form schemas declare URL-encoded input and return the generated ECR form with visible field errors and HTTP 422 when a well-formed request is invalid.
  • Malformed or unsupported form bodies preserve the framework's explicit 400 or 415 status instead of being flattened into a generic validation error.
  • Preview API generators bind the same executable schema contract for JSON writes while retaining structured JSON failures.
  • amber generate schema teaches the executable controller declaration as the primary application path; direct construction remains available for isolated schema unit tests.
  • The Unix and Windows generated-app smoke harnesses can test an exact framework repository and commit during coordinated development, while normal and release CI now exercise the published beta emitted by the template.

Upgrade compatibility

Amber's deprecated params.validation API remains functional. Existing Amber applications can update the framework first, verify their current behavior, and migrate validation one controller action at a time. CLI 2.0.6 changes new generators; it does not force an existing application to regenerate its controllers.

Release proof

  • 412 Amber CLI examples pass.
  • Apple Silicon macOS and x86_64 Linux release-style binaries generate, build, migrate, run, and exercise the complete web application.
  • Linux ARM64 and Windows x86_64 compile and run the generated web application in GitHub Actions.
  • The Pet Tracker smoke proves invalid HTML form input returns one HTML document with status 422 and a visible field error before proving persisted create and PATCH update behavior.
  • Fingerprinted CSS, JavaScript, SVG, and favicon responses retain integrity, MIME, immutable caching, URL rewriting, and gzip checks.

Windows remains a source-build compatibility path; this release publishes CLI archives for Apple Silicon macOS, x86_64 Linux, and ARM64 Linux.

Open the source release on GitHub →
v2.0.5Amber CLI 2.0.5

Amber CLI 2.0.5

Amber CLI 2.0.5 makes production-safe static assets part of the same supported Amber V2 web-app path as Grant, Micrate, and SQLite. A fresh application starts with editable CSS, JavaScript, SVG, and font locations; a deterministic asset manifest; manifest-aware ECR helpers; and browser-correct production headers.

Start a complete web app

Terminal
amber new pet_tracker --type web
cd pet_tracker
shards install
amber assets check
amber generate scaffold Pet name:string:required species:string:required adopted:bool
amber database migrate
crystal spec
amber watch

Open http://127.0.0.1:3000/ and http://127.0.0.1:3000/pets. The homepage uses the same Amber design language as the framework site and references fingerprinted files from public/assets/manifest.json.

What changed

  • Added amber assets build for deterministic fingerprinting and amber assets check for strict release verification.
  • Moved authored browser files to app/assets/; generated files under public/assets/ are ignored and may be rebuilt at any time.
  • Rewrites local CSS URLs and JavaScript module references to their fingerprinted image, font, stylesheet, and module targets.
  • Generates manifest-aware stylesheet, import-map, preload, image, and favicon tags, including Subresource Integrity metadata where browsers support it.
  • Rebuilds assets before application compilation in amber watch, including file additions, changes, and deletions.
  • Boots generated applications in Unix and Windows CI and requests the real HTML, CSS, JavaScript, SVG, and compressed-asset paths instead of treating a successful compile as sufficient evidence.
  • Publishes CLI archives for Apple Silicon macOS, x86_64 Linux, and ARM64 Linux; Windows x86_64 remains a source-build path with a release-gated app smoke.
  • Replaces the native preview generator's old personal and feature branches with the canonical Amber beta, released Asset Pipeline, and exact reviewed dependency revisions. Its documented make setup now fails visibly when dependencies cannot install instead of hiding the error.

Grant, SQLite, Micrate migrations, and generated HTML resource CRUD remain the default persistence contract from CLI 2.0.4. Native applications, authentication generators, and generated APIs remain preview surfaces.

Open the source release on GitHub →
v2.0.4Amber CLI 2.0.4

Amber CLI 2.0.4

Amber CLI 2.0.4 makes persistence part of the supported Amber V2 web-app path. A new application includes Grant ORM, SQLite, typed database settings, and Micrate-powered database commands by default.

Start a database-backed app

Terminal
amber new pet_tracker --type web
cd pet_tracker
amber generate scaffold Pet name:string:required species:string:required adopted:bool
amber database migrate
amber watch

Open http://127.0.0.1:3000/pets/new. The generated resource includes a Grant model, request schema, HTML CRUD controller, ECR views, specs, resource route, and reversible SQL migration. SQLite keeps the first run self-contained; pass -d pg or -d mysql to amber new for a server database.

What changed

  • Added Grant and the selected database driver to every generated web app.
  • Made SQLite the default database and connected development, test, and production settings through config/database.cr.
  • Embedded Micrate in amber database for migrations, status, rollback, redo, reset, and seeding.
  • Promoted model, scaffold, and migration generation to the supported beta path.
  • Corrected scaffold forms, optional fields, resource routes, and form-body handling so generated create and update requests persist successfully.
  • Added a release smoke test that generates a Pet resource, migrates both test and development databases, runs its specs, boots the app, creates a Pet, and updates it through the generated HTML forms.
  • Added a native Linux ARM64 release artifact and a Windows x86-64 generated-app compile gate.

Amber V2 native applications, generated authentication, and generated APIs remain preview surfaces in this release.

Open the source release on GitHub →