Multiple containers, same application, behind a caddy reverse-proxy routing to container 1 or 2 in function of the path

Hi, friends, loving caddy, although a bit newbie yet. First post here.

Newbie question

I have a question that maybe is basic for you, but worries me a lot:

I maintain a monolythic dashboard published at some URL like for example

It has multiple features gruped by routing, like for example those:


I run a caddy inside a docker container.

Currently the dashboard runs in another container behind the caddy, who maps all the internet traffic to into the internal container with something like this: {
    reverse_proxy * dashboard:80

where dashboard is the container name reachable from the caddy container.

The dashboard container serves the web from its internal root /.

Up to here, all works perfect.


The dashboard has been growing and we have approx 30 features. This reduces mantinainability of the code.

I want to split it into separated containers, something similar to a microservices approach but in the frontend. This will be a progressive splitting. Spring off feature-1 then next month feature-2 and so on.


Say I start by stripping feature-2 out into another container:

  • dashboard-old will serve all the features including the obsolete ones from /
  • dashboard-new will serve only the feature #2.

I’m wonder if caddy can help me to route:

  •* into http://dashboard-new/*
  •* into http://dashboard-old/*

Well in fact I already know that technically speaking it can. But there are 2 nuances I’m not sure how to handle: a) Path conversion and b) sessions.

My fear #1 - Path conversions

My fear #1 is about the “path conversion” back and forth from the outside and inside.

For example say the browser requests and it is routed to http://dashboard-new/something-cool

Until here, perfect.

But, what if this page contains links, AJAX requests, websockets, or whatever pointing to http://dashboard-new/tracking/id?

Reconverting this link from http://dashboard-new/tracking/nice to add again the stripped part feature-2 and rebuilding to seems something inside the HTML part and not the HTTP part.

As a context: I’m going to work with a dynamic frontend which is plenty of back-and-forth requests in the background (probably I’ll use React, not decided yet).

The intuition

I feel I should split the links into 2 groups: intra-feature and cross-feature.

  1. If I work ALL intra-feature links with relative paths I guess I should be done: Have the page render always tracking/id without the leading / I feel I should be okey here.

  2. And then use full hardcoded paths including the SSL schema for “jumping” to other features. If feature-2 has a global menu that allows to go to feature-1 and feature-3 that should be coded as the “externally accessible path” like

I have silly wonderings as: Would it be easier if I configure the internal feature-2 container to respond the document-root into the same path than the extenal call?

Ie: I wonder if this is needed or not needed but is better or it’s is a silly dumb hypothesis:

  •* into http://dashboard-new/feature-2/*
    instead of
  •* into http://dashboard-new/*

Fear #2 - Sessions

Appart from paths, there’s a huge problem with the sessions here… container dashboard-new needs to share session with dashboard-old.

I’ve no clue on if caddy plays a role here or not and where to start reading documentation about multi-container mono-session behind a caddy reverse proxy.

The help needed

Before going ahead, before spending days doing the feature segregation into another container, I want to ask you guys:

  • if any of you has any experience in placing “separated features” of the “same application” into splitted containers behind a caddy routing different paths
  • what are your good and bad experiences
  • and what are the things I should consider yes-or-yes before going ahead
  • session issues you have found

All your real-world experience in implementing all this is more than welcome!

I think your questions are more-or-less covered by this article:

I’d recommend that you use subdomains for each “feature”, so like or something similar.

That said, I’d say that microservice architectures… are a dangerous idea. You end up doing a lot of the same things in each one. Performance can suffer significantly because of added overhead.

Monolithic apps are fine.

1 Like

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