Buildpack Deployments

Buildpack deployments use Cloud Native Buildpacks to automatically detect your language, install dependencies, and build a production-ready container image -- no Dockerfile required.

How it works

Convoy Cloud clones your repository at the specified commit.
The buildpack detect phase identifies your language and framework.
The build phase installs dependencies and compiles your application.
The resulting image is stored in Convoy Cloud's private registry.
The image is deployed to your isolated environment.

You can watch each phase (detect, analyze, restore, build, export) in the live build logs.

Supported languages

Buildpacks auto-detect and support:

Language	Detection	Common frameworks
Node.js	`package.json`	Express, Next.js, Remix, Fastify, Nest.js
Python	`requirements.txt`, `setup.py`, `Pipfile`	Django, Flask, FastAPI
Go	`go.mod`	Gin, Echo, standard library
Java	`pom.xml`, `build.gradle`	Spring Boot, Quarkus, Micronaut
Ruby	`Gemfile`	Rails, Sinatra
PHP	`composer.json`	Laravel, Symfony
.NET	`.csproj`, `.fsproj`	ASP.NET Core
Static sites	`index.html`	Plain HTML/CSS/JS

Important: the PORT environment variable

Convoy Cloud injects a PORT environment variable into your application's runtime. Your application must listen on this port. The default is 8080.

Most frameworks respect PORT automatically:

// Node.js — Express
const port = process.env.PORT || 8080;
app.listen(port);

# Python — Flask
port = int(os.environ.get("PORT", 8080))
app.run(host="0.0.0.0", port=port)

// Go
port := os.Getenv("PORT")
if port == "" {
    port = "8080"
}
http.ListenAndServe(":"+port, nil)

Configuring the build

Start command

For Node.js apps, the buildpack uses the start script from your package.json:

{
  "scripts": {
    "build": "next build",
    "start": "next start -p $PORT"
  }
}

For Python apps, use a Procfile:

web: gunicorn --bind 0.0.0.0:$PORT app:app

Environment variables at build time

Environment variables configured in the deployment form are passed to the build process. This is useful for build-time configuration like API URLs or feature flags:

NEXT_PUBLIC_API_URL=https://api.example.com
NODE_ENV=production

Build caching

Buildpack builds maintain a separate cache per repository. Subsequent builds reuse cached layers (dependencies, compiled assets), significantly reducing build times.

When to use buildpacks vs. Dockerfile

Use buildpacks when...	Use Dockerfile when...
You want zero-config builds	You need full control over the build
Your app uses a standard framework	You have complex build steps
You want automatic security patches	You need a specific base image
You are getting started quickly	You want multi-stage builds for smaller images

Under the hood Buildpack builds run via Kpack using Cloud Native Buildpacks.

On this page