Frameworks supported

Brimble’s build pipeline auto-detects most popular frameworks and pre-fills the install, build, and start commands. This page lists what’s detected and what defaults you get. If your stack isn’t listed, set the commands manually under Configuration. Anything that runs in a Linux container will work, detection is a convenience, not a requirement.

​

How detection works

Brimble inspects:

• The repo root for known files (package.json, requirements.txt, Gemfile, go.mod, Cargo.toml, composer.json, pom.xml, build.gradle, mix.exs, Dockerfile).
• The contents of those files for framework-specific signals (e.g. next in dependencies).
• A few file-pattern checks (Procfile, wrangler.toml, etc.).

A Dockerfile at the repo root takes precedence, Brimble uses it directly and skips framework detection.

​

Node.js

Detected via package.json. Package manager auto-detected from lockfile: package-lock.json → npm, yarn.lock → yarn, pnpm-lock.yaml → pnpm, bun.lockb → bun. Node version auto-detected from engines.node in package.json or a .nvmrc file. Latest LTS by default.

​

Python

Detected via requirements.txt, pyproject.toml, or Pipfile. Python version detected from .python-version, runtime.txt, or pyproject.toml. Defaults to a recent stable version. Package manager: pip (requirements.txt), Poetry (pyproject.toml with [tool.poetry]), or pipenv (Pipfile).

​

Ruby

Detected via Gemfile. Ruby version from .ruby-version or Gemfile.

​

Go

Detected via go.mod.

• Service type: Web service.
• Build: go build -o app .
• Start: ./app

Go version from go.mod.

​

PHP

Detected via composer.json.

​

Java / Kotlin

Detected via pom.xml (Maven) or build.gradle / build.gradle.kts (Gradle). JVM version from pom.xml’s <java.version> or Gradle’s targetCompatibility.

​

Rust

Detected via Cargo.toml.

• Service type: Web service.
• Recommended: leave install and build empty; start ./bin/<app-name> (or leave start empty).
• The builder compiles with Cargo, copies the binary into bin/, and starts from there. Do not start from target/release/ — that path is not in the running image.

Full guide: Deploy a Rust app. Rust toolchain from rust-toolchain.toml or stable.

​

Elixir

Detected via mix.exs.

• Service type: Web service.
• Build: mix deps.get, mix compile, asset compilation if Phoenix.
• Start: mix phx.server or MIX_ENV=prod elixir --erl '-detached' -S mix run --no-halt.

​

Static-only frameworks

For all of the above, Brimble creates a static site project (no runtime container).

​

Dockerfile

If a Dockerfile exists at the project root, Brimble uses it directly:

• Build: docker build -t <image> .
• Start: docker run -e PORT=$PORT -p $PORT <image>

The Dockerfile must:

• Use EXPOSE for the listener port (or the container must listen on $PORT regardless).
• Run as a non-root user where possible.
• End with a CMD that launches your service in the foreground.

​

Custom commands

For any framework, detected or not, you can override under Configuration:

• Install command, typically the package manager install step.
• Build command, anything that compiles or bundles. Empty for runtime-only languages.
• Pre-start command, runs once per build, after the build, before the artifact is pushed. Useful for migrations.
• Start command, launches the runtime container. Must keep the process in the foreground.

The commands run in bash. Standard shell features (pipes, redirects, &&) work.

​

Language version selection

Most frameworks default to a recent stable version. Pin a specific version via the language’s standard mechanism:

• Node: engines.node in package.json, or .nvmrc.
• Python: .python-version, runtime.txt, or pyproject.toml.
• Ruby: .ruby-version or Gemfile.
• Go: go.mod’s go directive.
• Java: pom.xml <java.version> or Gradle targetCompatibility.

If detection picks the wrong version, the deployment logs will show the chosen version under the Detect phase. Pin explicitly to fix.