Some tools are so immediately useful that you wonder why you didn’t start using them sooner. Composerize and Decomposerize are in that category for me. If an open source project README gives me nothing but a long docker run command, these tools let me turn that into something I can actually work with — a proper Docker Compose file I can extend, pair with other services, version in Git, and reuse however I want.

1. Overview
2. The Problem with README-Only Docker Run Examples
3. Why I Like Composerize So Much
4. A Real Example: Converting Open WebUI from Docker Run to Compose
5. Extending the Stack with Additional Containers
6. One Nice Use Case: Coolify
7. Don’t Forget Decomposerize
8. Final Thoughts

1. Overview

I run into this all the time with open source software: the project is interesting, the README is decent, and the container quick start is a single docker run command.

That is fine for a five-minute test.

It is not how I want to operate something long term.

The moment I want to do any of the following, I want Docker Compose instead:

• persist data cleanly
• add a database, reverse proxy, or companion service
• manage environment variables in a sane way
• keep the configuration readable
• hand the stack to someone else without making them decode a giant one-liner
• deploy it anywhere that expects a Compose file

That is exactly why Composerize is so good. You paste in a docker run command, and it gives you a usable Compose starting point. Then, when you want to go the other way and sanity-check what a Compose service would look like as docker run, Decomposerize is the perfect companion.

2. The Problem with README-Only Docker Run Examples

A lot of open source projects document their container setup like this because it is fast and approachable:

docker run -d \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

There is nothing wrong with that command. In fact, for a quick smoke test, it is completely reasonable.

But if I want to actually use it, I immediately start asking questions like:

• Where do I put my other services?
• How do I version this config?
• What if I want to add Ollama beside it?
• What if I want to deploy this somewhere that wants Compose?
• What if I want to add labels, networks, env files, or named volumes later?

At that point, I am not interested in a one-liner anymore. I want structure.

3. Why I Like Composerize So Much

Composerize does one small thing, and it does it absurdly well.

You feed it a docker run command, and it translates the ports, volumes, restart policy, container name, environment variables, and other flags into a Compose service definition. That means instead of manually decoding a long command, I get a readable YAML file I can build on.

Using the Open WebUI example above, Composerize gives me a strong starting point that looks roughly like this:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: always
    ports:
      - "3000:8080"
    volumes:
      - open-webui:/app/backend/data

volumes:
  open-webui:

That alone saves time.

More importantly, it gets me out of “copy/paste command mode” and into “now I can actually shape this stack” mode.

4. A Real Example: Converting Open WebUI from Docker Run to Compose

Open WebUI is a good example because a lot of people first encounter it through a docker run snippet. That is useful, but I usually want more than a single container.

My workflow looks like this:

1. Copy the docker run command from the README
2. Paste it into Composerize
3. Take the generated Compose YAML
4. Clean it up a bit
5. Add the supporting services I actually want

Here is a more practical Compose version I would actually keep around. This is basically a simplified merge of Open WebUI’s main docker-compose.yaml and docker-compose.gpu.yaml, collapsed into one functional two-service file:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    pull_policy: always
    tty: true
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities:
                - gpu

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
      - WEBUI_SECRET_KEY=
    extra_hosts:
      - host.docker.internal:host-gateway
    volumes:
      - open-webui:/app/backend/data
    restart: unless-stopped

volumes:
  ollama: {}
  open-webui: {}

That is the kind of example I actually like in an article because it is not trying to be too clever. It works, it keeps the extra_hosts bit from the upstream Open WebUI compose file, and it keeps the GPU reservation block from the upstream GPU compose file.

If I wanted to run that on one of Gozunga’s Accelerated Compute GPU instances, that is exactly the point where Compose becomes more useful than a README one-liner. I can keep the app simple, expose Ollama on 11434, let Open WebUI reach it through host.docker.internal:11434, and still preserve the GPU-specific config for the ollama service.

In practice, that usually means:

• running it on a GPU-backed instance instead of a plain VM
• making sure the host has the NVIDIA driver and NVIDIA Container Toolkit/runtime available
• exposing Ollama on 11434 - host.docker.internal:host-gateway
• hardcoding a simple driver: nvidia and count: 1 GPU reservation for the example instead of making the reader deal with variables

That is where Composerize becomes more than a convenience tool.

It helps me get from “the README gave me a runnable demo” to “I now have an actual stack I can maintain.”

5. Extending the Stack with Additional Containers

This is the part I care about most.

Once I have Compose, I can start composing.

That means I can:

• add databases
• add Redis
• add an AI model backend like Ollama
• add a reverse proxy
• add a worker container
• join services onto the same network cleanly
• check the entire thing into Git

If I started with only a docker run one-liner, all of that expansion becomes annoying fast. With Compose, it is natural.

For example, maybe I want to add a lightweight reverse proxy in front of Open WebUI later, or maybe I want the app sitting alongside another internal service in the same project. Once the app exists as Compose YAML, I am working with infrastructure instead of a shell command.

That is a much better place to be.

6. One Nice Use Case: Coolify

Coolify is a good example of why this workflow matters, but it is not the only reason I use these tools.

Plenty of projects do not hand you a ready-made docker-compose.yml. They give you a Docker image and a docker run example and basically say, “good luck.” Composerize fills that gap.

If I want to deploy something in Coolify, the workflow is straightforward:

1. Grab the upstream docker run example
2. Convert it with Composerize
3. Clean up the YAML
4. Add any supporting containers I want
5. Add environment variables, volumes, domains, or labels as needed
6. Paste that into Coolify as a compose resource

That is just one practical example of the broader value here: once I have Compose, I am no longer trapped inside somebody else’s one-liner. I can adapt it for local use, share it with a team, check it into Git, or deploy it into something like Coolify when that makes sense.

7. Don’t Forget Decomposerize

Decomposerize deserves mention too because it is the natural companion to Composerize.

Sometimes I want to do the reverse:

• quickly understand what a Compose service boils down to
• compare a Compose definition against a README’s docker run example
• simplify something before sharing it with someone
• sanity-check whether I translated a service correctly

That is where Decomposerize is handy. It turns a Compose service back into docker run syntax, which is surprisingly useful for troubleshooting, documentation, and comparison.

Composerize gets me into Compose faster. Decomposerize helps me validate the result and reason about it from the other direction.

That pair is just incredibly practical.

8. Final Thoughts

I am a big fan of tools that remove friction without pretending to be more magical than they are.

Composerize does not replace knowing Docker Compose. It just removes the tedious translation step when a project only documents docker run.

That is enough to make it valuable.

And in practice, it is more valuable than it sounds because that translation step is exactly where a lot of self-hosting and deployment workflows slow down. Once I have Compose, I can adapt the app, add sidecars or dependencies, and make it fit whatever environment I actually want to run.

So yes, this is a fanboy post.

If you spend any time self-hosting open source software, Composerize should be in your toolbox.

And while you are at it, bookmark Decomposerize too.