blog-2025-02-14-java-dokploy-nixpacks

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin: programming language
• javalin: web framework
• gradle: build system
• dokploy: docker image hosting
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

(edit 2: turns out, [...]: def is a reference style link)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[ start ]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

(note: the [ start ] is without spaces of course, but pepperinos parser doesn't support escaping yet)

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin: programming language
• javalin: web framework
• gradle: build system
• dokploy: docker image hosting
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[ start ]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

(note: the [ start ] is without spaces of course, but pepperinos parser doesn't support escaping yet)

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

kotlin, dokploy

• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[ start ]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

(note: the [ start ] is without spaces of course, but pepperinos parser doesn't support escaping yet)

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[ start ]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

(note: the [ start ] is without spaces of course, but pepperinos parser doesn't support escaping yet)

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[ start ]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

(note: the [ start ] is without spaces of course, but pepperinos parser doesn't support escaping yet)

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[ start ]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[`start`]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
\start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
\\start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
[start\]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
\[start\]
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
\start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin on the jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• kotlin @ jvm: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• jvm kotlin: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something else)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• jvm kotlin: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so it must be something different)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• jvm kotlin: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so )

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• jvm kotlin: language
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but ~there seems to be a bug in pepperino's alias handling~ - update: it shows up here so )

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

(edit: the first link is kotlin, but there seems to be a bug in pepperino's alias handling)

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• foo
• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"

yesterday i ran into troubles deploying my current side project filemure.

my current dev stack is:

• javalin: web framework
• gradle: build system
• nixpacks: building a docker image

and

• sqldelight: database wrapper
• tempolin: html templating

i ran into a few problems this time, compared to when i worked on pepperino:

1. don't forget to make it a fat jar by including john engelman's shadow. i think it's not necessary to change the build command, but build creates both a thin and a fat jar and then it might not be clear which one of the two the start.cmd selects.
2. if it's a multi module project, either copy the jar to root build/libs directory (which is where nixpacks looks by default), or overrule it in the nixpacks config

providers = ["java"]

# add shadowJar
[phases.build]
cmds = ["chmod +x gradlew", "./gradlew clean shadowJar -x check -x test"]

# new path, and we can know the actual jar name
start
cmd = "java $JAVA_OPTS -jar app/build/libs/app-all.jar"