Creates dynamic virtual hosts for any docker web container you launch.
Clone or download
mwinckler Set COMPOSE_CONVERT_WINDOWS_PATHS environment variable on Windows
Docker 18.03.0 and later have a regression which causes a "mount denied - <path> is not a valid Windows path" error when attempting to mount /var/run/docker.sock via docker-compose.yml. As documented in docker/for-win#1829, setting the `COMPOSE_CONVERT_WINDOWS_PATHS` environment variable to a truthy value works around this issue.
Latest commit c2af55b May 16, 2018

Tugboat, automatic reverse proxy for containers

tugboat logo

This project contains a fabio reverse proxy, consul, and registrator. When used together, they can create dynamic virtual host for any web container you launch.

This project requires that you are using Docker for Windows, Mac, or Linux. At the time of this writing, Docker Toolbox is not available for Linux, but docker-compose is available to download here.

This means every new container (when lightly configured) you launch, will have a custom hostname you can pull up in your browser.

Yes. Really.


How to run:

  1. Clone this repo.
  2. Run make start

How to get your project working

You need to add the following 5 lines to your service you want load balanced to docker-compose.yml

  - 3000 #ensure this is the correct port your service exposes
  - "SERVICE_3000_NAME=awesome-service" #adjust the port number here too, if needed
  - "SERVICE_3000_TAGS=urlprefix-awesome-service.*/"

Note: the ports line should NOT look like 3000:3000. It should be a single port number only. This allows docker to assign a RANDOM port to bind to on the host. Consul / Registrator / fabio will handle this random port without issue. This prevents you from experiencing port conflicts!

Now run docker-compose up on your project.

Then simply go to (docker toolbox) or (docker native) in your browser (because we set the name to be awesome-service)

SSL Support

This project by default provides SSL support using a self-signed SSL cert for *

The self-signed certificate likely will not work well for internal app-to-app communication since it will likely reject the cert. We personally just use http for that (it's internal anyways!), but you also have the option to use your own SSL certificate.

Custom Configuration

To use a custom configuration (enable SSL, custom SSL cert, custom domain) please run:

cp docker-compose.override.example.yml docker-compose.override.yml and then edit to your needs.

Note: If you use a custom domain, you need to also setup wildcard DNS to the IP So if you use the domain, you need to setup * to point to

We own and have wildcard DNS set up for the following domains:


Static Custom Configuration

Are you at company where you want all of your devs to use the same custom configuration? Well we are too, so we have you sorted there as well!

Head on over to Tugboat Bootstrapper to learn how to create a repo with static configs


None of the tugboat domains are resolving

There are two causes of this:

  1. You are using a router that has "rebind production" turned on, you will need to turn that off, or add an exception for this domain. DD-WRT and Open-WRT often enable it by default.
  2. Your DNS server doesn't allow hostnames to resolve to local IPs (eg: 192.168.x.x). You can try using Google's DNS servers ( and


  1. Fork it ( )
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create a new Pull Request


  • Check out the contributors here