[Feature] Default environment variables #130

New Issue

GiteaMirror · 2025-10-31T15:02:51-05:00

GiteaMirror commented

2025-10-31 15:02:51 -05:00

Originally created by @em411 on GitHub (Nov 15, 2024).

Description

Currently, when creating a new stack in Komodo, the Environment form section provides a basic placeholder format # VARIABLE = value. While this is helpful for beginners, it's not so useful for advanced users who frequently use the same environment variables across different stacks.

Use Case

Common variables like PUID, PGID, or TZ can be preset
Users can still maintain flexibility by modifying pre-populated values when needed

Example images

Originally created by @em411 on GitHub (Nov 15, 2024). # Description Currently, when creating a new stack in Komodo, the Environment form section provides a basic placeholder format ``# VARIABLE = value``. While this is helpful for beginners, it's not so useful for advanced users who frequently use the same environment variables across different stacks. # Suggested Solution Add a "Default" checkbox option in the variables settings that allows users to: - Mark specific environment variables as default - Automatically populate default variables when creating new stacks # Use Case - Common variables like ``PUID``, ``PGID``, or ``TZ`` can be preset - Users can still maintain flexibility by modifying pre-populated values when needed # Example images ![image](https://github.com/user-attachments/assets/46baf939-4e99-470a-9b6f-ad81fe877212) ![image](https://github.com/user-attachments/assets/feb33d59-2cd2-41d5-b28d-4c199b38fb88)

GiteaMirror added the enhancement label 2025-10-31 15:02:51 -05:00

GiteaMirror closed this issue

2025-10-31 15:02:51 -05:00

GiteaMirror commented

2025-10-31 15:02:51 -05:00

@mbecker20 commented on GitHub (Nov 16, 2024):

Reminds me of #28

@mbecker20 commented on GitHub (Nov 16, 2024): Reminds me of #28

GiteaMirror commented

2025-10-31 15:02:51 -05:00

@em411 commented on GitHub (Nov 16, 2024):

Default vars and global vars, while seemingly similar, serve distinct purposes and would complement each other rather than be interchangeable.

Default vars act as a template/preset for new stack initialization, where users expect to modify values per stack's specific needs. For example, having a default value for DOMAIN pointing to internal domain name is useful as a starting point, but some stacks will need to change it to external domain for public facing services. The main difference is that updating default vars doesn't affect existing stacks - it only applies to new ones, making it a simpler, more predictable feature.

Global vars, on the other hand, should function (in my opinion) as a singleton that affects all stacks uniformly, both existing and new. When you update a global var, the change propagates automatically across all stacks, making it a more complex feature that requires proper state management and update handling. This behavior is essential for values that should remain consistent across your application, like API keys or base path for bind mount directory.

Another advantage of default vars is that they serve as documentation of common configuration patterns. Users can quickly understand the expected environment structure by looking at the default template, while still maintaining the freedom to adjust values as needed.

In essence, default vars focus on initialization convenience while preserving stack independence, whereas global vars emphasize unified configuration management across all stacks.

@em411 commented on GitHub (Nov 16, 2024): Default vars and global vars, while seemingly similar, serve distinct purposes and would complement each other rather than be interchangeable. Default vars act as a template/preset for new stack initialization, where users expect to modify values per stack's specific needs. For example, having a default value for ``DOMAIN`` pointing to internal domain name is useful as a starting point, but some stacks will need to change it to external domain for public facing services. The main difference is that updating default vars doesn't affect existing stacks - it only applies to new ones, making it a simpler, more predictable feature. Global vars, on the other hand, should function (in my opinion) as a singleton that affects all stacks uniformly, both existing and new. When you update a global var, the change propagates automatically across all stacks, making it a more complex feature that requires proper state management and update handling. This behavior is essential for values that should remain consistent across your application, like API keys or base path for bind mount directory. Another advantage of default vars is that they serve as documentation of common configuration patterns. Users can quickly understand the expected environment structure by looking at the default template, while still maintaining the freedom to adjust values as needed. In essence, default vars focus on initialization convenience while preserving stack independence, whereas global vars emphasize unified configuration management across all stacks.

GiteaMirror commented

2025-10-31 15:02:51 -05:00

@mbecker20 commented on GitHub (Nov 17, 2024):

Yeah I understand. I realize there is an existing usage pattern available that should satisfy your use case and more, call it the template pattern.

You may have noticed every Resource in Komodo has a "Copy" button available, you just enter a new name and it keep the same config. You can leverage this by creating template resources thats only use is as the source resource with the Copy api.

For example, create a new Deployment just called "template", and add the environment variables you want as defaults there. When you want to create a new Deployment, just navigate to the template use the Copy button.

While it is slightly less convenient to have to navigate to the template before creation, I don't think this impact is big (it takes seconds using the Search). Additionally, this pattern has several advantages:

You can create multiple templates for different systems you manage, each with their own defaults.
In addition to Environment, you can default other config parameters such as Network, Restart Mode, or Labels.
You can create a ResourceSync pointing to your template resources, version them with git, and use GitOps to manage your templates over time.

You can also leverage the simple API available for all resources to create new resources from template resources for automations, for example can use this call in an Action:

komodo.write("CopyDeployment", { name: "my-new-deployment", id: "template" })

Overall I think universal configurable defaults is not adding enough value to justify this feature in addition to the template pattern. Please try out this pattern for your use case and let me know any difficulties you come across, and we can re-asses how to make this process more straightforward.

Already I see one way, which I will implement: When you click "New ..." buttons, currently you input the Name and hit create. Right below the name, can have a selector allowing to choose from your resources to copy from. Can also mark a resource as default for the template. The flow of this solution should be very similar to what you are looking for.

@mbecker20 commented on GitHub (Nov 17, 2024): Yeah I understand. I realize there is an existing usage pattern available that should satisfy your use case and more, call it the **template** pattern. You may have noticed every Resource in Komodo has a "Copy" button available, you just enter a new name and it keep the same config. You can leverage this by creating template resources thats only use is as the source resource with the Copy api. For example, create a new Deployment just called "template", and add the environment variables you want as defaults there. When you want to create a new Deployment, **just navigate to the template use the Copy button**. While it is slightly less convenient to have to navigate to the template before creation, I don't think this impact is big (it takes seconds using the Search). Additionally, this pattern has several advantages: 1. You can create **multiple templates for different systems you manage, each with their own defaults**. 2. In addition to Environment, **you can default other config parameters** such as `Network`, `Restart Mode`, or `Labels`. 3. You can **create a ResourceSync pointing to your template resources**, version them with git, and use GitOps to manage your templates over time. You can also leverage the simple API available for all resources to create new resources from template resources for automations, for example can use this call in an Action: ``` komodo.write("CopyDeployment", { name: "my-new-deployment", id: "template" }) ``` Overall I think universal configurable defaults is not adding enough value to justify this feature in addition to the template pattern. Please try out this pattern for your use case and let me know any difficulties you come across, and we can re-asses how to make this process more straightforward. Already I see one way, which I will implement: When you click "New ..." buttons, currently you input the Name and hit create. Right below the name, can have a selector allowing to choose from your resources to copy from. Can also mark a resource as default for the template. The flow of this solution should be very similar to what you are looking for.

GiteaMirror commented

2025-10-31 15:02:52 -05:00

@gitcatpeter commented on GitHub (Nov 17, 2024):

I'm replying to the above (not to hijack @em411 thread) as well as to mine - issue #183.

Easily created Stacks template using Copy, seems that that approach would work for me well.
Also what you proposed sounds good:

Already I see one way, which I will implement: When you click "New ..." buttons, currently you input the Name and hit create. Right below(...)

Thanks!

@gitcatpeter commented on GitHub (Nov 17, 2024): I'm replying to the above (not to hijack @em411 thread) as well as to mine - issue #183. --- Easily created **Stacks** template using Copy, seems that that approach would work for me well. Also what you proposed sounds good: `Already I see one way, which I will implement: When you click "New ..." buttons, currently you input the Name and hit create. Right below(...)` Thanks!

GiteaMirror commented

2025-10-31 15:02:52 -05:00

@em411 commented on GitHub (Nov 18, 2024):

Thanks @mbecker20 for this great idea.

I'm currently in the process of migrating my numerous stacks from Dockge to Komodo. While the migration is progressing slowly but surely, I wanted to provide some constructive feedback about both the main pain points and what I believe are relatively simple improvements that could be implemented without too much effort.

Update

Copy works like a charm. I was able to avoid most of the tedious work of migrating all my containers from Dockge.

@em411 commented on GitHub (Nov 18, 2024): Thanks @mbecker20 for this great idea. I'm currently in the process of migrating my numerous stacks from Dockge to Komodo. While the migration is progressing slowly but surely, I wanted to provide some constructive feedback about both the main pain points and what I believe are relatively simple improvements that could be implemented without too much effort. --- ### Update ``Copy`` works like a charm. I was able to avoid most of the tedious work of migrating all my containers from Dockge.

GiteaMirror referenced this issue

2025-10-31 15:19:27 -05:00

[PR #248] [MERGED] 1.17.0 #713

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#130