Deploy Without a Dockerfile: AI Build Agent vs. Buildpacks

You can deploy without a Dockerfile in two fundamentally different ways: with a buildpack, which matches your project against a fixed set of rules and fails when nothing matches, or with an AI build agent, which reads your actual source files and writes a deployment plan from what it finds. Buildpacks are faster and deterministic when your project looks like the projects they were written for. An AI build agent handles the cases buildpacks reject — a single app.py with no requirements.txt, an app that needs an OS package installed before npm install, or a bot that won't start until you supply a token. On JustRunMy.App, the second path is the Runny AI Agent: you drop a .zip, it analyzes, builds, deploys, then watches the logs to confirm the app actually stayed up.

How buildpacks decide what your app is#

A buildpack build runs in two phases: detect, then build. During detect, each buildpack in the builder inspects your source tree for a marker file — package.json for Node.js, requirements.txt for Python, and so on — and declares whether it applies. DigitalOcean App Platform, for instance, uses the Heroku Node.js buildpack to detect and build Node apps (DigitalOcean docs).

If no buildpack group passes detection, the build stops before it starts. The error is familiar to anyone who has used the model: No buildpack groups passed detection, or Railway's equivalent "unable to generate a build plan." The cause is almost always the same — the repository doesn't contain the marker files the detector needs to identify the app type (Kinsta troubleshooting docs).

This model is worth taking seriously. It is fast, cacheable, reproducible, and it powers a large share of the market. Railway replaced Nixpacks with Railpack in 2026 specifically to make these builds smaller and faster, cutting image sizes by 38% for Node and 77% for Python (Railway blog). Zero-config detection is a solved problem for projects that fit the template.

The gap is everything else. A rule-based detector can only recognize what someone encoded in advance. It cannot read your code and reason about it.

What an AI build agent does instead#

The Runny AI Agent starts from the same input — your project, no Dockerfile required — but treats it as something to investigate rather than pattern-match. It runs as a staged pipeline, and each stage produces evidence the next one uses:

1. Preflight digest — a deterministic pass over the unpacked archive that catalogs files, manifests, and runtime signals.
2. Project exploration — the agent reads and greps actual files to understand what the project is.
3. Safety screening — a check for clearly abusive payloads (credential stealers, DDoS tools, crypto miners). Obfuscated code alone isn't grounds for rejection; the posture is conservative.
4. Runtime detection — classify the runtime from evidence, not from the presence of a filename.
5. Package detection — work out what actually needs installing, including packages implied by imports rather than declared in a manifest.
6. Runtime-specific planning — produce a concrete deployment plan: SDK version, install command, run command, working directory, environment variables, exposed ports.
7. Execution — build the image and start the app.
8. Monitoring — wait, then read the live logs and status to decide whether it's genuinely healthy.
9. Debrief — on failure, diagnose and submit a fix plan, then retry once.

Three cases where the difference shows up#

A Python file with no requirements.txt#

A single app.py that imports Flask, with no requirements.txt and no pyproject.toml, is a detect-phase failure for a buildpack — the marker file it looks for isn't there. The agent's runtime detection stage is instructed to treat this as Python anyway, classify it from the import and entrypoint evidence, and let package detection supply the pip install hints. Missing manifests are a reason to look harder, not a reason to reject.

That said, keeping your manifests is still the better path — the panel's own quick-start says so explicitly: keep dependency manifests (package.json, requirements.txt, pyproject.toml). Evidence-based detection is a fallback for when they're absent, not a license to omit them.

An app that needs OS packages, not just language packages#

Headless Chromium is the classic example. npm install puppeteer succeeds; the app then crashes at runtime on a missing libnss3 or libgbm. Nothing in package.json records that dependency, so no manifest-driven detector can anticipate it.

The agent catches this on the other side of the deploy. Its monitor stage reads the actual container logs looking for stack traces, missing-module errors, port binding failures, and OOM kills — and it is explicitly told not to trust a green status, because the platform restarts a crashed process in a supervised loop without incrementing the container's restart counter. An app that looks RUNNING can still be crash-looping. When the debrief stage sees missing Chromium libraries, the fix is to expand the install command with the OS packages and rebuild.

An app that can't start without a secret#

A Discord bot with a DISCORD_TOKEN placeholder will build cleanly and then fail on first run. A buildpack has no way to ask you for it — the build either succeeds or it doesn't, and configuration is your problem afterward.

The agent can pause mid-run and request the specific environment variables it needs, with a name, a title, and a description for each. You submit them, the platform sets them on the app at create time, and the agent resumes. It never receives the values — the deployment plan carries the variable names with empty values, and the platform fills them in. Framework-level variables like NODE_ENV, PORT, or ASPNETCORE_URLS are set automatically and never asked about; only real application secrets trigger the prompt.

What it supports, and what it doesn't#

Being specific here matters more than sounding capable:

• Runtimes. Detection and planning are built around Python, Node.js, and prebuilt .NET publish output, on Linux x86. .NET is a runtime container for publish output — publish first, then upload; the agent won't run dotnet build for you. .NET 6 isn't supported.
• Archive size. ZIP up to 50 MB. Zip from your project root and leave out node_modules, venv, dist, and bin/obj — they're rebuilt during the install step and they'll push you past the limit for no benefit.
• Retries. One. The debrief stage gets a single fix-and-retry; if that attempt also fails, the deployment is reported failed with a reason rather than looping.
• Build quota. Runny AI builds are metered per day and shown on the Limits page as Runny AI Builds per 1 day, alongside your CPU, RAM, disk, app-count, and exposed-port quotas.
• Not a library runner. Libraries, SDKs, and one-shot CLI scripts are rejected as unsupported app types — there's nothing to keep running.

When you should still write a Dockerfile#

Zero-config deploys — buildpack or agent — are for the common case. Write a Dockerfile when you're outside it: an unusual runtime, a multi-stage build you've already tuned, system dependencies you want pinned explicitly, or a build you need to reproduce byte-for-byte in CI. The Advanced tab covers those paths directly.

• Git Push — push a repo; a Dockerfile at the root is used if present.
• Docker Push — build locally, push the image, run it.
• Existing Image — point at an image in a third-party registry.

A useful way to think about it: use the agent to get from "a folder of code" to "a running app" quickly, and reach for a Dockerfile once you know exactly what the container should be.

FAQ#

Can I deploy an app without writing a Dockerfile?#

Yes. Either a buildpack detects your stack from marker files like package.json or requirements.txt and builds an image for you, or an AI build agent reads your source and generates the build and run configuration itself. Both produce a container without you authoring one.

What's the difference between a buildpack and an AI build agent?#

A buildpack applies fixed detection rules and fails when no rule matches. An AI build agent inspects the actual files, infers the runtime and dependencies from evidence, and can recover from a failed first attempt by reading the logs and adjusting.

Why does my buildpack build fail with "no buildpack groups passed detection"?#

No buildpack in the builder recognized your project — usually because the marker file it detects on is missing, or the build is pointed at the wrong directory. Adding the expected manifest at the project root normally fixes it.

Do I still need a requirements.txt or package.json?#

Not strictly for the Runny AI Agent, which can classify a project from imports and entrypoints. Include them anyway — detection is faster and more accurate with them, and you avoid depending on inference for something you can state outright.

What happens if the deploy fails?#

The agent diagnoses the failure from the deployment plan, build output, and container logs, then makes one corrective attempt — changing the run command, install command, SDK version, ports, or env vars. If that fails too, it reports the reason instead of retrying indefinitely. You can read the container output yourself at any time via logs.

Does the agent see my API keys?#

No. When it needs a secret, it requests the variable by name; the platform stores the value and sets it on the app. The value never enters the agent's context.

Wrapping up#

"No Dockerfile required" means two different things depending on who's saying it. With buildpacks it means your project matches a known shape. With an AI build agent it means something read your code and worked it out — which is why the interesting difference isn't the happy path, where both work fine, but the failure path: a missing manifest, an undeclared OS dependency, a secret nobody asked for. Upload a zip in the AI-assisted deploy flow and the worst case is a failed build with a stated reason, not a detection error you have to decode.