long domain names produce unexpected errors #872

New Issue

2026-06-19T13:58:29Z

fauno commented

2026-06-19 13:58:29 +00:00

we're having long domain names, with several levels of subdomains. some recipes cause errors when the domain name is used as the stack name and it surpases the 64 character limit of secrets and config names, for instance.

yesterday we had a traefik deployment error where it was complaining a config name wasn't following the [a-z0-9][a-zA-Z0-9.-_]+[a-z0-9] pattern. i'm typing this from memory because i didn't save screenshots, the idea is that it was alphanumeric with dots, dashes and underscores allowed only in the middle.

it was fixed when we reduced the domain name, but the issue was that the stack name was reduced to somewhat_long_doma_ and turned into somewhat_long_doma__file_provider_yml_v1, docker wasn't accepting the double underscore, and the pattern not matching error was misleading.

i can come back with actual errors, i didn't want to forget to report this!

we're having long domain names, with several levels of subdomains. some recipes cause errors when the domain name is used as the stack name and it surpases the 64 character limit of secrets and config names, for instance. yesterday we had a traefik deployment error where it was complaining a config name wasn't following the `[a-z0-9][a-zA-Z0-9.-_]+[a-z0-9]` pattern. i'm typing this from memory because i didn't save screenshots, the idea is that it was alphanumeric with dots, dashes and underscores allowed only in the middle. it was fixed when we reduced the domain name, but the issue was that the stack name was reduced to `somewhat_long_doma_` and turned into `somewhat_long_doma__file_provider_yml_v1`, docker wasn't accepting the double underscore, and the pattern not matching error was misleading. i can come back with actual errors, i didn't want to forget to report this!

fauno added the bug label 2026-06-19 13:58:29 +00:00

decentral1se commented

2026-06-21 12:53:33 +00:00

More information would be welcome and --debug logs also!

We have code that ultimately tries to avoid these errors over here 👇

		abra/pkg/app/app.go
		Lines 134 to 146 in c3a2048eba
	
				// StackName gets whatever the docker safe (uses the right delimiting

				// character, e.g. "_") stack name is for the app. In general, you don't want

				// to use this to show anything to end-users, you want use a.Name instead.

				func StackName(appName string) string {

					stackName := SanitiseAppName(appName)

					if len(stackName) > config.MAX_SANITISED_APP_NAME_LENGTH {

						log.Debug(i18n.G("trimming %s to %s to avoid runtime limits", stackName, stackName[:config.MAX_SANITISED_APP_NAME_LENGTH]))

						stackName = stackName[:config.MAX_SANITISED_APP_NAME_LENGTH]

					}

					return stackName

				}

It's really an annoying limitation which we can't really do much about except for reducing length of inputs if we detect it and there is really no other option. A workaround is to hack STACK_NAME=foo into your .env.

		abra/pkg/app/app.go
		Lines 123 to 125 in c3a2048eba
	
					if _, exists := a.Env["STACK_NAME"]; exists {

						return a.Env["STACK_NAME"]

					}

More information would be welcome and `--debug` logs also! We have code that ultimately tries to avoid these errors over here 👇 https://git.coopcloud.tech/toolshed/abra/src/commit/c3a2048eba010a30afada889cc44d75a61ebf5ee/pkg/app/app.go#L134-L146 It's really an annoying limitation which we can't really do much about except for reducing length of inputs if we detect it and there is really no other option. A workaround is to hack `STACK_NAME=foo` into your `.env`. https://git.coopcloud.tech/toolshed/abra/src/commit/c3a2048eba010a30afada889cc44d75a61ebf5ee/pkg/app/app.go#L123-L125

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#872

	if _, exists := a.Env["STACK_NAME"]; exists {
	return a.Env["STACK_NAME"]
	}