Public | Automated Build

Last pushed: 21 hours ago
Short Description
Build agents that monitor and act on your behalf. Your agents are standing by!
Full Description

Huginn for docker with multiple container linkage

This image runs a linkable Huginn instance.

There is an automated build repository on docker hub for cantino/huginn.

This was patterned after sameersbn/gitlab by ianblenke/huginn, and imported here for official generation of a docker hub auto-build image.

The scripts/init script generates a .env file containing the variables as passed as per normal Huginn documentation.
The same environment variables that would be used for Heroku PaaS deployment are used by this script.

The scripts/init script is aware of mysql and postgres linked containers through the environment variables:




Its recommended to use an image that allows you to create a database via environmental variables at docker run, like paintedfox / postgresql or centurylink / mysql, so the db is populated when this script runs.

If you do not link a database container, a built-in mysql database will be started.
There is an exported docker volume of /var/lib/mysql to allow persistence of that mysql database.

NOTE: If you do not export the volme, or use a linked database container, you cannot update Huginn without losing your data.

Additionally, the database variables may be overridden from the above as per the standard Huginn documentation:

DATABASE_ADAPTER #(must be either 'postgresql' or 'mysql2')

This script will run database migrations (rake db:migrate) which should be idempotent.

It will also seed the database (rake db:seed) unless this is defined:


This same seeding initially defines the "admin" user with a default password of "password" as per the standard Huginn documentation.

If you do not wish to have the default 6 agents, you will want to set the above environment variable after your initially deploy, otherwise they will be added automatically the next time a container pointing at the database is spun up.

The CMD launches Huginn via the scripts/init script. This may become the ENTRYPOINT later. It does take under a minute for Huginn to come up. Use environmental variables that match your DB's creds to ensure it works.


Simple stand-alone usage (use only for testing/evaluation as it can not be updated without losing data):

docker run -it -p 3000:3000 cantino/huginn

Use a volume to export the data of the internal mysql server:

docker run -it -p 3000:3000 -v /home/huginn/mysql-data:/var/lib/mysql cantino/huginn

To link to another mysql container, for example:

docker run --rm --name huginn_mysql \
    -e MYSQL_DATABASE=huginn \
    -e MYSQL_USER=huginn \
    -e MYSQL_PASSWORD=somethingsecret \
    -e MYSQL_ROOT_PASSWORD=somethingevenmoresecret \
docker run --rm --name huginn \
    --link huginn_mysql:mysql \
    -p 3000:3000 \
    -e HUGINN_DATABASE_NAME=huginn \
    -e HUGINN_DATABASE_PASSWORD=somethingsecret \

To link to another container named 'postgres':

docker run --name huginn_postgres \
    -e POSTGRES_PASSWORD=mysecretpassword \
    -e POSTGRES_USER=huginn -d postgres
docker run --rm --name huginn \
    --link huginn_postgres:postgres \
    -p 3000:3000 \
    -e HUGINN_DATABASE_PASSWORD=mysecretpassword \
    -e HUGINN_DATABASE_ADAPTER=postgresql \

The docker/multi-process folder also has a docker-compose.yml that allows for a sample database formation with a data volume container:

cd docker/multi-process ; docker-compose up

Environment Variables

Other Huginn 12factored environment variables of note, as generated and put into the .env file as per Huginn documentation. All variables of the .env.example can be used to override the defaults which a read from the current .env.example.

For variables in the .env.example that are commented out, the default is to not include that variable in the generated .env file.

Building on your own

You don't need to do this on your own, because there is an automated build for this repository, but if you really want:

docker build --rm=true --tag={yourname}/huginn .


The source is available on GitHub.

Please feel free to submit pull requests and/or fork at your leisure.

Docker Pull Command
Source Repository

Comments (6)
2 days ago

Hi, I encounter an issue with Huginn and docker networks, I use two network, a bridge one to access huginn, and an internal one to connect Huginn and its mysql database (because --link is deprecated). Here is my docker command : docker create --name=huginn --restart=always --net=bridge --net=dmz-huginn-db -e DATABASE_ADAPTER=mysql2 -e DATABASE_HOST=mysql -e DATABASE_PORT=3306 -e HUGINN_DATABASE_NAME=huginn -e HUGINN_DATABASE_USERNAME=huginn -e HUGINN_DATABASE_PASSWORD=XXX cantino/huginn

and when I start the container and access the logs, i get:

2017-03-24T13:34:57.269351477Z Generating random APP_SECRET_TOKEN.
2017-03-24T13:34:57.886964877Z 1+0 records in
2017-03-24T13:34:57.887000044Z 1+0 records out
2017-03-24T13:34:58.085636996Z 36 bytes (36 B) copied, 0.000211826 s, 170 kB/s
2017-03-24T13:36:22.334204421Z Fetching source index from
2017-03-24T13:37:19.943990069Z Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from
2017-03-24T13:37:43.871303318Z Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from
2017-03-24T13:38:07.183529093Z Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from
2017-03-24T13:38:10.707125988Z Could not fetch specs from

But it seems to work fine with only one network.

a year ago

I've managed to deploy Huginn to my Dokku with a native MySQL database using this small Dockerfile:

FROM cantino/huginn
MAINTAINER <my email>


2 years ago

the port is 3000,not 5000!
use docker run -it -p 3000:3000 cantino/huginn!

2 years ago

The usage section explaining how to link to another mysql container doesn't work on my system.

The client container cannot connect to mysql server's container. I'm not sure the ports are exposed the right way ?

2 years ago

There is a fix for my previous comment :
You can also start docker with env variable :
docker run -it -p 5000:5000 -e SCHEDULER_FREQUENCY=0.3 cantino/huginn

2 years ago

I tried this on Ubuntu 14.10 and CentOS 7 but each one consumes 80% CPU without any request coming in. Ruby2.1 (bin/threaded.rb) is eating all the CPU.
Seems to be an issue in there.