Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Confluence in Docker container replaces confluence.cfg.xml on launch Edited



I use the following command to start Confluence in a Docker container:


docker run -v ~/Docker/confluence:/var/atlassian/application-data/confluence --name="confluence" -p 8090:8090 -p 8091:8091 atlassian/confluence-server


The server starts up fine and I complete setup with the built-in database and an example site.


As soon as I stop and restart the container, Confluence greets me with the setup dialog again. Confluence shows the following messages in its startup log:


$ docker start -a confluence

INFO:root:Generating /opt/atlassian/confluence/conf/server.xml from template server.xml.j2

INFO:root:Generating /opt/atlassian/confluence/confluence/WEB-INF/classes/seraph-config.xml from template seraph-config.xml.j2

INFO:root:Generating /opt/atlassian/confluence/confluence/WEB-INF/classes/ from template

INFO:root:Generating /var/atlassian/application-data/confluence/confluence.cfg.xml from template confluence.cfg.xml.j2

INFO:root:User is currently root. Will change directory ownership to confluence then downgrade permissions

INFO:root:Running Confluence with command '/bin/su', arguments ['/bin/su', 'confluence', '-c', '/opt/atlassian/confluence/bin/ -fg']

executing as current user

If you encounter issues starting up Confluence, please see the Installation guide at


As you can see, Confluence overrides my existing confluence.cfg.xml with an empty template file.

What am I missing here? Do I have to pass an environment variable for Confluence to pick up its existing configuration file?


I was able to reproduce this issue on an Ubuntu 18.04 Server and on a Mac running macOS 10.14.6, both using the latest Docker version.

Thank you for your help!




I conducted a little research and found out that the 'confluence.cfg.xml' is generated by a script called '' in the root directory of the container. I also found out that I can specify my database configuration with the following environment variables:





But even with these variables set, Confluence still boots to the setup screen on subsequent launches.

I wonder if this script is supposed to run on every container start? If so, how can I inject the remaining values (e.g. the license) and skip the setup? If not, how can I skip the generation step on subsequent launches of the container?

My current workaround is to inject a copy of '' into the container without the generation command. But this is merely a bad workaround and likely to cause issues with future updates. 

6 answers

1 accepted

3 votes
Answer accepted
Dave Chevell Atlassian Team Aug 22, 2019

This should now be fixed! Apologies for the showstopper bug. All versions have been rebuilt with a fix that doesn't overwrite an existing confluence.cfg.xml file.

Thank you for the quick fix. It's working for me now.

Does this fix only concern the confluence.cfg.xml? I pulled the atlassian/confluence-server:latest yesterday and can not edit the server.xml. It get's reset to the templat on each restart of the container.

Dave Chevell Atlassian Team Sep 03, 2019

Hey @domdom ,

If you need to overwrite a config file (confluence.cfg.xml, server.xml) instead of using the normal method of supplying all configuration values in the environment, here's the supported way to do that:

All of these configuration files have templates that are stored in `/opt/atlassian/etc/`. They are Jinja2 templates (e.g. `confluence.cfg.xml.j2`), however you can overwrite them with a "plain" configuration file. For example:

FROM atlassian/confluence-server:latest

COPY confluence.cfg.xml /opt/atlassian/etc/confluence.cfg.xml.j2

We'll be updating our README's to explicitly document this as the way to overwrite the built in Jinja2 templates with your own custom config files.

Hope that helps!


If you want to edit items as proxyName, proxyPort, secure and scheme for the reverse proxy add this enviroments in the docker-compose file as follows:


Like focus likes this

Thanks for your replies and helping me understand. A lot of ressources asking me to "edit server.xml" led me on the wrong path.

They rebuilt all Docker containers 2 days ago and introduced a new entrypoint, which overwrites existing config files with values from environment. But they simply forgot to document it on Docker Hub...


Anyway, my infrastructure is documented in a git repository and i don´t want any credentials stored there!


Same with Jira Docker images. Actually it´s a bug, they write on Docker Hub database environment variables are optional and you can set up via web gui on first start, but second time container starts, file will also be overwritten by entrypoint script.


Really, Atlassian???


My fix is to change file permissions of config files to 0400.

The file permission change of the confluence.cfg.xml to 0400 didn't work for me as the following snippet from the runs as root and simply overwrites the existing file:

f"{env['confluence_home']}/confluence.cfg.xml", env,
user=env['run_user'], group=env['run_group'], mode=0o640)

 The workaround from FelixII worked, but as he already stated is only a temporary solution. 

Haven´t tested yet, too much downtime for a day...

But changes file permissions after trying to write the file.


def gen_cfg(tmpl, target, env, user='root', group='root', mode=0o644):"Generating {target} from template {tmpl}") cfg = jenv.get_template(tmpl).render(env) with open(target, 'w') as fd: fd.write(cfg) set_perms(target, user, group, mode)

/ will run on every start rewriting your confluence.cfg.xml. If you set your database environment variables or not, license is still missing and you will always get the setup screen.

I have same problem with replacing confluence.cfg.xml and I have to stay with version 6.15.5 which is the last working one :( In another topic@xbb suggested to use to another and functional image, but I prefer this one from Attlassian.

I tried a lot of versions and I think 6.15.5 is affected too, as Atlassian rebuild almost every image a few day ago, probably with an updated Dockerfile which now copies the problematic file:

I guess you still have an old version of 6.15.5 on your server, and docker didn't pulled it again as it was already present. To be safe, better tag your current in use version, so you can fallback.

You're right, I didn't pull the 6.15.5 again. I'm lucky, I used the downloaded version.

i have the same issues with seraph-config

Dave Chevell Atlassian Team Sep 04, 2019

Hi @Philipp Kayser ,

See my above answer further up this page. You can supply your own version of the file by overwriting the template in /opt/atlassian/etc/seraph-config.xml.j2 (e.g. by building a new image with ours as the base image, then adding a COPY command to overwrite the template with your own)

Let me know if I’ve misunderstood or if that doesn’t help!

I found two issues (in 6.15.19) that I'm having to work around.

1) /'s gen_cfg function has its "Overwrite" argument set to True by default.  I have to wonder why you'd *always* want to replace the config file with it's template version.  I changed this to be False.

2) The files which are being replaced (e.g. server.xml, confluence.cfg.xml, etc.) are already present in the base image anyway!  If the entrypoint is going to replace these anyway, I don't see why they're present to begin with.  If they weren't there, then a new container would create them anyway.  I changed it so these files aren't in the image.

Here's my Dockerfile that applies these changes:



FROM atlassian/confluence-server:${CONFLUENCE_VERSION}-ubuntu-${UBUNTU_VERSION}-adoptopenjdk8

# set default behavior to NOT overwrite configuration files with their corresponding templates
RUN sed -i 's/overwrite=True/overwrite=False/' /

# Remove files whose presence would otherwise block the template versions from being
# copied in their place.  This will result in the template versions only being used 
# when a new container is created from this image and when the user does not provide 
# a host volume which binds to those paths in the container.
RUN rm -f ${CONFLUENCE_INSTALL_DIR}/{conf/server.xml,confluence/WEB-INF/classes/seraph-config.xml,confluence/WEB-INF/classes/,confluence.cfg.xml} ${CONFLUENCE_HOME}/confluence.cfg.xml


@Dave Chevell , you suggested a custom Docker image to work around this, but is there a reason my changes couldn't just be applied to Atlassian's official image?  It seems like it'd still work, at least for the use cases that I can imagine.  Thanks.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Confluence

What do you think is the most *delightful* Confluence feature? Comment for a prize!

- Create your own custom emoji 🔥 - "Shake for Feedback" on mobile 📱 - An endless supply of GIFs via GIPHY 🤩 Is there anything quite as nice as a pleasant surprise? Comment below with what...

408 views 23 8
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you