# Amber: a Crystal web framework with a Rails-shaped CLI > Amber is a Crystal web framework that borrows Rails conventions and ships a scaffolding CLI. It is aimed at Crystal developers who want generators and a full-stack layout rather than a bare router, and its current line is still in beta. **amberframework/amber** — A Crystal web framework that makes building applications fast, simple, and enjoyable. Get started with quick prototyping, less bugs, and blazing fast performance. - Repository: https://github.com/amberframework/amber - Website: https://amberframework.org - Stars: 2,605 · Forks: 205 - Language: Crystal - License: MIT - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/amberframework-amber ## What Amber is for, and who it is aimed at Amber is a web application framework written in Crystal. The README states the project was inspired by Kemal, Rails, Phoenix and Hanami, and that its purpose is to take advantage of Crystal's language capabilities rather than to add another framework to the pile. The stated goal is an efficient, cohesive web framework that follows Crystal's conventions and guidelines. That framing matters when you decide whether to look further. Kemal is a routing library with a small surface; Amber sits above that level and gives you a project structure, a command line tool and generators. If you have written a Rails or Phoenix application, the vocabulary will be familiar. If you have only used a Crystal HTTP server directly, the amount of generated structure is the main thing to weigh. The audience is narrow by construction. Crystal is a compiled language with a smaller ecosystem than Ruby or Elixir, so choosing Amber means choosing Crystal first. The README points readers at the documentation site for the quick start guide and the CLI command reference, which is where the actual usage detail lives; the repository README itself is mostly installation and contribution instructions. ## The CLI is the product, not just a helper The repository layout makes the design visible. The build target in the Makefile is src/amber/cli.cr, so the compiled binary is the CLI itself. Under src/amber/cli/templates/app there is a shard.yml.ecr template, which is how a generated application gets its dependency list. The release checklist in the README includes a step to repoint amber to the master branch in that template, which tells you generated apps depend on Amber through a Git reference rather than a published package. That has a practical consequence. A generated project's shard.yml carries a github: reference, and the release process explicitly manages whether that reference points at master or a tag. If you generate an app and then pin nothing, you are tracking a branch. The README's own dependency example shows the same shape: ```yaml dependencies: amber: github: amberframework/amber ``` There is no version constraint in that snippet. For a beta release line, that is the single most important thing to fix in a generated project before you build anything on top of it. The rest of the mechanism is conventional. Amber compiles to a single binary, and the Makefile builds it with crystal build against src/amber/cli.cr with the -p flag and --no-debug. Dependencies come from shards install. The docker-compose.yml in the repository shows the runtime shape the project expects for its own test suite: a postgres service on 5432, a redis service on 6379, and a spec container that runs bin/amber_spec with DATABASE_URL, REDIS_URL and AMBER_ENV set to test. That is the environment a generated app is designed to fit into. ## Installing Amber and generating a first application On macOS and Linux the README gives Homebrew as the short path: ```bash brew install amber ``` On Linux the README states that source is currently the only option, and lists the system packages the build needs before you clone: ```bash sudo apt-get install libreadline-dev libsqlite3-dev libpq-dev libmysqlclient-dev libssl-dev libyaml-dev libpcre3-dev libevent-dev git clone https://github.com/amberframework/amber.git cd amber shards install make sudo make install ``` The README notes that at the time of writing v1.4.1 was the current stable release and that you should substitute the most recent tag. It also gives an Arch Linux route through yay. After make install the binary lands in /usr/local/bin/amber, which is the INSTALL_DIR the Makefile defines. If you would rather not install globally, the README offers a per-project build. Running this inside a project produces bin/amber in that project only, which is the option I would take when trying the beta line: ```bash shards build amber ``` To use Amber as a dependency instead of a tool, the README gives the shard.yml entry shown in the previous section. From there the README directs you to the quick start guide and the CLI command reference on docs.amberframework.org for the actual generator commands; the repository README does not list them, so treat the documentation site as the source for command names and flags rather than guessing at them. ## Where Amber is the wrong choice The release history is the first thing to check. The three most recent releases are v2.0.0-beta.5, v2.0.0-beta.4 and v2.0.0-beta.3, dated 2026-08-13, 2026-08-12 and 2026-08-11. The last push to the repository was on 2026-08-13. The project is not archived, but the current line is a beta, and the README's Linux instructions still describe v1.4.1 as the stable release. If your team has a policy against depending on pre-release software, that policy alone rules Amber out for now, regardless of how the framework is designed. The second constraint is the dependency reference. Because the release checklist treats repointing the shard.yml template at master as a release step, a generated application can end up tracking a branch. Combined with a beta release line, that means an application you generate today may need deliberate pinning before it is reproducible. The third is the platform story. Homebrew covers macOS and Linux, and Arch users have a package, but the README is explicit that source is the only Linux option it documents. That is a build toolchain requirement, not a one-line install, and it means the machine doing the build needs the development headers for Postgres, MySQL, SQLite, OpenSSL, YAML, PCRE and libevent. Finally, if what you want is a single-file HTTP service, Amber is more framework than the job needs. Kemal, which the README names as an inspiration, is the smaller tool for that case. ## Amber against Kemal, and against staying in Ruby Kemal is the closest comparison and the README names it first among the inspirations. The difference is one of level, not of quality. Kemal gives you routing and middleware in a small API; you decide the directory layout, the configuration and the database wiring. Amber gives you a generated application with a CLI that produces that structure for you, plus a template system and an ORM layer implied by the Full ORM category the README uses when it points at the TechEmpower results. If you want to read the framework's source to understand your application, Kemal is the smaller surface. If you want to be told where things go, Amber is the one with opinions encoded in generators. The other comparison worth making is against Rails or Phoenix, which the README also cites. The reason to pick Amber over either is Crystal: compiled output, static typing and the language's own concurrency model. The reason not to is ecosystem. Rails and Phoenix have years of published gems and libraries behind them; Amber's documentation site and Discord are the support surface the README offers. That trade is the whole decision, and it should be made on the language first. ## Licence and the cost of keeping up Amber is MIT licensed. The README states this and points at the LICENSE file. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved in copies or substantial portions. It does not come with a patent grant, and it does not impose copyleft on your application. That is a summary of what the licence identifier means, not legal advice; read LICENSE before you ship. Upgrade cost is harder to estimate from the repository alone. The versioning is the reason. With v2.0.0 still in beta and v1.4.1 described in the README as the stable release, there is a real question about which line an existing application is on and what moving between them involves. The README does not document a migration path between the two, and the release checklist is about publishing Amber itself rather than about upgrading applications built with it. What the repository does give you is a test path. The docker-compose.yml defines a spec service that runs bin/amber_spec against postgres and redis with AMBER_ENV set to test, and the contributing section tells contributors to run ./bin/amber_spec before committing. That is the command to run in your own project when you bump the Amber reference, because it is the same command the project uses on itself. ## Conclusion Adopt Amber if you already write Crystal and want generators, a project layout and a CLI that produces a working skeleton rather than assembling a router by hand. Do not adopt it if you need a stable, non-beta release line or you are not prepared to build the CLI from source on Linux, where the README states source is the only option. Before committing, check the release tag you intend to pin, whether the shard.yml template in src/amber/cli/templates/app points at master or at a tag, and whether the beta line's changelog covers the generator behaviour you depend on. ## FAQ ### How do I install Amber on Linux? The README states that source is currently the only option on Linux. It lists the apt packages to install first, then git clone, shards install, make and sudo make install; Arch users are pointed at yay -S amber. ### How do I use Amber as a dependency in my shard.yml? The README gives the entry under dependencies with github: amberframework/amber. Note that the snippet carries no version constraint, so you should add a tag yourself if you need a reproducible build. ### What is the current stable release of Amber? The README says v1.4.1 was the current stable release at the time of writing, while the most recent releases listed are v2.0.0-beta.5, v2.0.0-beta.4 and v2.0.0-beta.3. The README does not document a migration path between the two lines. ### What licence does Amber use? The README states the project is licensed under the MIT License and points at the LICENSE file in the repository. ### How do I run Amber's test suite? The contributing section says to run ./bin/amber_spec. The docker-compose.yml defines a spec service that runs bin/amber_spec with DATABASE_URL, REDIS_URL and AMBER_ENV set to test against postgres and redis. ## Sources - [amberframework/amber on GitHub](https://github.com/amberframework/amber) - [License: MIT](https://github.com/amberframework/amber/blob/master/LICENSE) - [Project website](https://amberframework.org) - [README](https://github.com/amberframework/amber/blob/master/README.md) - [Releases](https://github.com/amberframework/amber/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/amberframework-amber