Issue with SWAG Container getting parsing credential error

Hi all,

I'm new on here and I've come looking for help, I've installed the SWAG reverse proxy using docker compose on an Ubuntu 20.04 Server in order to expose some services, the install seems to have been done correctly but I'm running into an issue after the start of the container. Please note that I'm using Portainer to manage the container, also FWIW, I'm using the Cloudflare API token in the .ini file.

Not sure where I've messed up so would really appreciate if you guys could point me in the right direction.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: start swag container from Portainer

It produced this output: Error parsing credentials configuration: Invalid line ('1234567') (matched as neither section nor keyword) at line 10.

Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

ERROR: Cert does not exist! Please see the validation error above. Make sure you entered correct credentials into the /config/dns-conf/cloudflare.ini file.

My web server is (include version):

The operating system my web server runs on is (include version):Docker on Ubuntu server 20.04

My hosting provider, if applicable, is: selfhosting

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.32.0

Thanks in advance for your help.

1 Like

Welcome to the community @elgringo

First, you proxied your DNS in Cloudflare so are using their CDN. The SWAG docs say not to do this and leave the DNS setting "gray". See the docs (link here). Related item:

On Cloudflare, we'll click on the orange cloud to turn it grey so that it is dns only and not cached/proxied by Cloudflare, which would add more complexities.

As for your parsing error, that looks like you edited the Cloudflare ini file wrong. The same link above describes this config file (sort of). But, I believe it should look like:

dns_cloudflare_email =
dns_cloudflare_api_key = yourglobalapikey

I am not expert at your setup and just found that sample w/google. The text of the error sounds like your format is wrong in that file.


Hi MikeMcQ,

Thanks for the response, I was going by what I found on the following link cerbot as at first I did used the email and the api_key but was getting the same error, hence why I decided to look for some help here; I just reverted back the changes again to use the email and API_key again but still have the error so not sure what is causing this.

1 Like

The error could only really be caused by one thing, which is an errant line in a credentials file that reads:


If I had to guess, somebody copied the example from the plugin documentation and accidentally pressed a newline after the leading 0 in the example.

Maybe you can try grep your system for that line:

sudo grep -R "^1234567" / 2>/dev/null

What is in this file? Replace your actual api key with "xxx"

I still see your DNS proxied at Cloudflare. That isn't causing this parse error but it changes how you configure certs.


here's my .ini file:

# Instructions:
# Replace with your values

# With global api key:
dns_cloudflare_email =
dns_cloudflare_api_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# With token (comment out both lines above and uncomment below):
#dns_cloudflare_api_token = xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

if you see it as proxied is because as it's not working I reverted back that change as well, I've gone and unproxied again and have restarted the container and stil the same issue, I've now left it unproxied.

Have you tried the grep like _az suggested?


sorry, yes I have and this is what I got, looks like is still thinking about it and so far nothing pointing to the .ini file

ok, managed to get this working, I restarted from scratch, I believe that _az was spot on on his response, as after redeploying the container with fresh files and paying attention to the copy/paste, it managed to get things rolling.

Thank you all for your help


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.