Raypacks (Beta)

Raypacks is the builder that turns your code into a running app on Nubo. Point it at a repo, and it figures out what you’re shipping (a Go service, a React app, a static site, a Node bot), runs the right build, and produces a container image. No Dockerfile. No docker build. No buildpack stack to learn. It’s the default builder for new Frames.

​

Why Raypacks exists

We started with Paketo (Cloud Native Buildpacks). It works, but builds were slower than we wanted and the configuration knobs (the BP_* environment variables) felt like buildpack trivia rather than something you’d reach for. Raypacks is what we built to replace it. What’s different:

• Daemonless. No background Docker daemon. Builds run in an isolated, ephemeral build environment that shuts down when finished.
• Auto-detection first. Drop in a go.mod, a package.json, or an index.html and Raypacks picks the right pack. No config required for the common case.
• Real config when you need it. Override anything via nubo.toml at the repo root. See nubo.toml reference.
• Cached. Module downloads (Go modules, the npm/pnpm/yarn download cache, layer digests) persist between builds of the same Frame.

​

The four packs

Detection runs top to bottom. The first pack that matches wins.

​

When to use the classic builder (Paketo)

Raypacks has packs for Go, Node, static sites, and Dockerfiles. Anything it doesn’t have a pack for falls to the classic Paketo (Cloud Native Buildpacks) builder: Python, PHP, and C apps build on Paketo. Rust isn’t a supported stack on Nubo yet. Raypacks is in Beta. If you hit something it doesn’t cover (a stack outside the four packs, or a niche BP_* knob you relied on), switch the Frame’s Builder to Paketo in Frame Settings, or pin it per Frame in nubo.toml with builder = "paketo" (or the stack = "paketo" escape hatch). Paketo isn’t going anywhere; it’s the fallback while Raypacks grows.

​

Where to go next