Adding Request Headers – Dokploy & Traefik

I’ve switched over to hosting all my sites with Dokploy. I’ve been enjoying the switch, but have found that there are a few settings which aren’t as simple as clicking a button. This isn’t a limitation of Dokploy, but rather a feature. Instead of abstracting away from the underlying system that serves your websites, Dokploy lets you manage them with a no-fuss interface. One of the changes I needed to make was for this website: Setting the access-control-allow-origin header. This is how you add/change it using Traefik within Dokploy.

Before You Start

I’m going to detail the exact circumstances for which this guide is written. While it’ll likely be applicable to many other deployments made with Dokploy, I cannot guarantee that this is a one-size-fits-all solution. So please bear this in mind.

I have…

• A WordPress website, set up as a Docker Compose project.
• This uses the wordpress:latest image.
• Current Dokploy version as of writing this article: v0.21.8

Review The Generated Compose

When you have a Docker Compose project, you can choose to ‘Preview Compose’.

This shows you the actual compose configuration that will be used to serve your project. This extra layer is required as Dokploy takes your desired configuration and then adds the more complicated under-the-hood bits to serve your project via Traefik.

If we look at the various configurations in the above screenshot, you’ll see that jackwhitworthcom-wordpress-qhppys-7-web is used across all of them. This is the project’s slug, which you’ll require to add your own configurations.

Adding Headers to Traefik with Dokploy

Exiting from the preview, to add an access-control-allow-origin header to my project, it’s as simple as adding this to the compose file:

services:
  wordpress:
    image: wordpress:latest
    environment:
        ... # removed for this example
    volumes:
        ... # removed for this example
    networks:
      - dokploy-network
    labels:
      - traefik.http.routers.jackwhitworthcom-wordpress-qhppys-7-web.middlewares=redirect-to-https@file,cors-headers
      - traefik.http.routers.jackwhitworthcom-wordpress-qhppys-7-websecure.middlewares=cors-headers
      - traefik.http.middlewares.cors-headers.headers.accessControlAllowOriginList=*
      - traefik.http.middlewares.cors-headers.headers.accessControlAllowMethods=GET,OPTIONS,PUT,POST,DELETE
      - traefik.http.middlewares.cors-headers.headers.accessControlAllowHeaders=*

networks:
  dokploy-network:
    external: true

There are two things happening here:

On lines 11 and 12, we’re telling the project (via the slug we found earlier) to use a new middleware called cors-headers. Line 11 is for redirecting non-SSL requests, and line 12 is for serving secure SSL requests.

Note: The rule on line 11 already existed in the originally generated compose from Dokploy, but it didn’t include the extra cors-headers rule. That’s why it had to be redeclared entirely with the new rule added.

Next, lines 13, 14 and 15 are where we create the cors-headers middleware, which previously didn’t exist. You can learn more about these specific rules by checking out Traefik’s header documentation. This will always be more verbose, accurate, and up-to-date than any information I could provide here on that topic.

Deploying Our Changes

Now that we have our new rules, be sure to click ‘Save’ on the bottom-right of the page, and then ‘Deploy’ at the top. This will rebuild the container and refresh the Traefik configuration with our new rules.

You can also use the ‘Preview Compose’ button again to verify your new labels are showing.

Testing The Header

My preferred way to test the headers is to load up a page being served from this project and to use the networking tab in the browser. Hit F12, go to ‘Networking’, and then refresh the page. You’ll see all of the requests listed on the dev tools window, the first of which should be for the page itself. You can review the response headers in that request. Here’s a screenshot showing where it is/how it looks with Firefox:

Troubleshooting

If you have deployed the changes and aren’t seeing the new header, you can try some of the following:

• Check the ‘Preview Compose’ button to ensure the new labels are present.
• Check that the slug for your project is correct and that it matches the others in the generated compose.
• Redeploy the app again.
• Disable/review any CDNs such as Cloudflare, as headers can be modified by these services.