Dynamic Parameters for Hugo


Is there any way to pass dynamic parameters to hugo config ? What I mean that, I would like to show/hide some contents in my application according to the user type who was login.

Simply I can do this when I build my website for professionals only for example as below but I need to this more dynamic way which depends on the user type who was login.

So I will deploy my app to kubernetes but dont know really I can handle this via dockerize multiple sites therefore any suggestion or help will be appreciated…

hugo server -D -e professional


├── _default
│   └── config.toml
├── professional
│   ├── config.toml
│   └── params.yaml
└── trainer
    ├── config.toml
    └── params.yaml


The closest I know needs to host on Netlify.

You can use branch deploys and split testing to create opt-in versions of your site. Ideal for giving people access to features which are in beta, or other special items.

To serve content dynamically based on a user login, I would not use Hugo.

Instead, I’d look at dynamic content management systems (e.g., Drupal, WordPress) where access control is a foundational element. For example, Drupal controls access by user, role, or group at the site level, by content type, by node, by field, etc.

1 Like

www.plone.org is really great in this area too. But those are other beasts.

1 Like

So unfortunately we build everything on Hugo at the present… Our login feature added after…

So cant we find any workaround for this with Hugo ?

So, may be you can get inspiration from the Netlify way of doing it, and manage yourself access to different branches thru ngnix and your server setup if you need to host this yourself ??

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

— Abraham Maslow’s Law of the Instrument

1 Like

Why not build separate sites for the different user types, and (re)direct them to the appropriate one based on their login? If you are using kubernetes anyway, then it should be relatively simple I guess (I mean, compared to the complexity of kubernetes itself).

This is the logic behind Netlify feature (they use branches and cokie name of the “active” branch)

So the issue is, we display/hide some sections inside the content.I mean in same content some has to be visible for employees some parts only for trainers some parts for all… Also the confusion is, let assume ı am a employee and other user login also at the same time … So everyime should I build the site again?I also do not understand the logic behind using branches

  • no
  • yes :slight_smile: Did you looked at the video ? It is well explained

What Netlify propose is:

  • to build different versions of your site.
  • each version in a branch
  • each version for a different public.

Then, you affect a special cookie for each branch for each public.
They do that in the demo (btw dis you looked at the video :slight_smile: ?) with a button “VIP opt-in”.
But you can do that the way you want.

Then their CDN does the job for presenting different branches according to the cookie.

PS : did you looked at the video :slight_smile: ??

No. You BUILD different branches for different public


This is actually what I planned but I confused a bit also. So let assume I’ve two sites for two different users it means ı will have two Pods running for each sites… The questions that I have,

  1. How can I pass the user info to hugo or according to the this infra or no need to do that ?
  2. If I not mistaken, I can handle this maybe to setup a ingress such as nginx or traefik to redirect users to appropriate one, am I correct ? Can I expose them in a same domain and just put this logic on proxy?


Yeah I watched the video and seems got the point but I need to deploy this web site in our private kubernetes clusters.

As I asked above, the confusion I 've how to pass the user info or I do not need to do this cause I deployed two different sites and the only thing that I need to do is redirect them to proper site as I understood.

Is there anythings else should I take care or think over about it ?


  1. For similar purposes, we use two different hugo config files: a parameter is set to true in one of them, and to false in the other. The different builds use the different hugo files, and our page templates include/exclude the page based on this parameter. If you need to exclude info within a page, you can write a shortcode that checks the config parameter and decides whether to display the content or not.
  2. Since ingress configuration is very flexible in Kubernetes, you can probably do that with the same domain, but I am not an expert.

May I add that Hugo qualifies splendidly as a front presentation app/layer in a decoupled scenario with Drupal as backend. But, hey, it’s probably too late for the purposes of the author of this thread

yeah this is totally ı did the same so far…Ok appreciate for your supports