@bnhf Just a thought to consider.
I know your EZ Start was heading in this direction.
It would be so much easier for new users if there were a simplified two step setup for OT4C;
STEP 1 - Use a simplified docker compose with no environment variables just to get OT4C up & running.
- Have an OT4C Settings page UI where users can add/change setting with good explanations of what each is for.
- This Settings page could have links to online documentation.
- Use a permanent/persistant Settings file to hold all settings, especially those not needed to create the container.
- Once the user has made all the required settings in the Settings page UI, display a docker compose without environment variables to use in STEP 2.
STEP 2 - Create the finalized OT4C container using the compose statement displayed in STEP 1
- This container will use the permanent/persistant Settings file instead of env vars.
- This container will also have the same OT4C Settings page UI that accesses the permanent/persistant Settings file.
- Keeping any settings not needed to create the container in the settings file will simplify things for the user.
I know you seem to like env vars in portainer stacks, but it's very confusing having to figure out from comments in the compose statements which env vars need to be set to what and which are required vs. optional and even samples can be confusing if a user is unfamiliar with host and domain names vs. IP addresses.
When I use Portainer stacks I like to include everything in the compose statement and eliminate environment variables not absolutely necessary.
Not even sure if this is possible, but if so I'm sure it would eliminate a lot of troubleshooting in setting up OT4C.
And if STEP 1 isn't possible in OT4C, perhaps it could just be a web page.
After all, whether the compose statement or environment variables are changed in a stack, it has to be redeployed.
The only environment variable I could imagine being needed is the host volume mapping for /config, storage of the persistant settings/config file
But a user could just modify the compose statement instead.
Or perhaps it could be a named docker volume (which I've never used, so not sure).
services:
olivetin-bootstrap:
# 2026.07.02
# GitHub home for this project: https://github.com/bnhf/OliveTin
# Docker container home for this project with setup instructions: https://hub.docker.com/r/bnhf/olivetin
container_name: olivetin-bootstrap
hostname: olivetin-bootstrap
image: bnhf/olivetin:bootstrap
ports:
- 1337:1337
environment:
- OLIVETIN_COMPOSE=2026.07.02 # Do not change this value.
- UPDATE_SCRIPTS=true # Set this to true to update all included scripts.
- UPDATE_YAMLS=true # Set this to true to update config.yaml.
volumes:
- ${OLIVETIN_HOST_DIR}:/config # Change ${OLIVETIN_HOST_DIR} to the directory on your Docker host used to store OLIVETIN config and settings files, like /volume1/docker/olivetin If running on Synology docker, this directory must first be created by the user.
- /var/run/docker.sock:/var/run/docker.sock
restart: unless-stopped
environment variables:
OLIVETIN_HOST_DIR=/volume1/docker/olivetin
