GetLaunchGetLaunch
Try it free

Docker Image Deployment

New Docker image projects are no longer available. This page is for projects created before container projects were retired. To build a web app, use AI Workspace.

Deploy any pre-built public Docker image directly without needing a Git repository.

Overview

Docker Image Deployment lets you run pre-built containers from Docker Hub or any public registry. Instead of managing Dockerfiles in Git, you simply reference an image and getlaunch.dev handles the rest.

This is perfect for deploying stateless applications like nginx, Node.js apps, Python services, or any other stateless public Docker image.

Supported Registries

You can deploy from any public Docker image source:

  • Docker Hub — official and community images: nginx, node, python
  • Docker Hub with tags — specific versions: nginx:1.21, node:18-alpine
  • GitHub Container Registry — ghcr.io/owner/image:tag
  • Any public registry — as long as the image is publicly accessible

Note: Private registries and images requiring authentication are not supported. Your Docker image must be publicly pullable.

Creating a Project

  1. Go to Projects → New Project
  2. Select Deploy from Docker Image
  3. Fill in:
    • Project name — your deployment name (e.g. my-web-server)
    • Docker Image — the image reference (e.g. nginx:latest, node:18-alpine, ghcr.io/owner/repo:v1.0)
    • Port — the port your container listens on (e.g. 80 for nginx, 3000 for Node.js)
    • Environment variables (optional) — configuration for your container
  4. Click Create Project

The image will be validated to ensure it's publicly accessible. If validation fails, double-check the image name and ensure it's available on Docker Hub or your registry.

Port Configuration

Every Docker image deployment requires a port — the port your container listens on internally.

For example:

  • nginx listens on port 80
  • Node.js Express typically listens on port 3000 or 8080
  • Python Flask typically listens on port 5000
# Example: run locally to find the port
docker run nginx # Check logs for "listening on port X"

Once deployed, getlaunch.dev exposes your container on the public internet, routing traffic to the port you specified.

Environment Variables

Docker image deployments support environment variables for configuration. Set them through your project settings.

# Example for a Node.js application
NODE_ENV=production
LOG_LEVEL=info
DATABASE_URL=postgresql://user:pass@host/db

Environment variables are injected at runtime. Changes take effect immediately on the next deployment trigger.

Deployment & Auto-Deploy

Docker image projects use manual deployments only. There is no auto-deploy feature because images don't have a Git commit to trigger from.

To deploy:

  1. Go to your project
  2. Click the Deploy button
  3. The image will be pulled from the registry and started on your platform

Each deployment pulls the image at that moment. If you want to force an update:

  • Tag your image with a specific version (nginx:1.21 instead of nginx)
  • Or use nginx:latest to always pull the newest version on each deployment

Image Updates & Tags

Latest tag: If you deploy nginx or nginx:latest, each deployment pulls the most recent version.

# Always pulls latest
docker_image: "nginx"

# Always pulls version 1.21
docker_image: "nginx:1.21"

Once a deployment is running, it stays on the image pulled at deployment time. To upgrade to a new image version:

  1. Edit your project settings (change the image reference)
  2. Click Deploy again

There is no automatic update mechanism — you control when new versions are deployed.

Data Persistence & Stateless Architecture

Docker image deployments run on a stateless architecture similar to serverless platforms. This means:

Data is not persistent:

  • Any data stored inside the container will be lost when you redeploy, update, or restart
  • Application logs are not saved
  • User-uploaded files are deleted
  • Database records (if using SQLite or local storage) are lost
  • Runtime configuration changes are discarded

CPU is request-driven:

  • Your container only consumes CPU when handling requests
  • Idle containers use no CPU resources
  • Billing is based on actual request processing time, not uptime

For applications that need persistent data:

  • Databases: Use external PostgreSQL, MySQL, MongoDB (hosted services)
  • File storage: Cloud storage (AWS S3, Google Cloud Storage)
  • Configuration: Store in environment variables or external config services
  • Caching: Use external Redis or similar services

Example with external PostgreSQL:

# Instead of local SQLite, use an external database
DB_HOST=postgres.example.com
DB_PORT=5432
DB_NAME=myapp
DB_USER=postgres
DB_PASSWORD=secure_password

This architecture is ideal for:

  • ✅ Web servers (nginx, Apache)
  • ✅ APIs and microservices
  • ✅ Processing jobs and workers
  • ❌ NOT for long-running background tasks without external state
  • ❌ NOT for applications that require persistent local storage

Resource Limits & Billing

Docker image deployments are containers and subject to the same resource limits and billing as repository-based container deployments.

  • Quotas: Starter plan includes 2 container deployments (Docker image or Git-based)
  • Billing: Usage-based pricing on CPU, memory, and data transfer. See Pricing for details
  • Scaling: Containers auto-scale based on traffic. Idle containers cost nothing

Limitations

  • No auto-deploy: Manual trigger only
  • No custom Dockerfile: Deploy pre-built images only
  • No build customization: Image runs as-is from the registry
  • Public registry required: Private registries not supported
  • No Git tracking: No commit history or rollback to previous Git versions (though you can redeploy an older image tag)
  • Stateless only: Data is not persisted — use external databases and storage services for persistent data

Suitable Applications

Docker image deployments work best for stateless applications. Here are examples of containers you can deploy:

# Web servers
nginx
nginx:1.21
apache2

# Node.js applications
node:18
node:18-alpine

# Python applications
python:3.11
python:3.11-slim

# Reverse proxies & load balancing
traefik

# Static site servers
nginx:latest (serving pre-built static sites)

❌ Not suitable for:

  • Databases (PostgreSQL, MySQL, MongoDB, SQLite)
  • Caches that require persistence (Redis, Memcached)
  • Applications that store files locally
  • Stateful services that need data to survive restarts

Troubleshooting

"Docker image not found or not public" — The image doesn't exist, is private, or isn't accessible. Check:

  • Image name spelling and tag
  • Registry status (Docker Hub may have temporary issues)
  • If using a private registry, switch to a public image

"Port X is already in use" — The port is invalid or restricted. Try another port (1024–65535).

Container crashes immediately — The image may require environment variables or mounts you haven't configured. Check the image documentation and add required env vars in your project settings.

Can't connect after deployment — Verify:

  • The container is actually listening on the port you specified
  • Firewall or security group rules allow inbound traffic
  • The application inside the container is running correctly (check deployment logs)