Yeeted

HOSTING FOR AI-BUILT APPS

Deploy a Java app built by Maven on Yeeted

A small slug API in Java 21 on the JDK's own HTTP server, built by Maven from pom.xml with no Dockerfile. Yeeted detects pom.xml, runs mvn package -DskipTests in a Maven image, copies the single jar from target/ into a Java 21 runtime image, and starts it with java -jar. The Java URL shortener covers the other Java path, where the project ships its own Dockerfile.

There is no framework on purpose: the only things under test are the platform's Maven detection and its runtime image. JUnit is the sole dependency, at test scope. The Gradle twin has the same source, built by Gradle instead.

Tests: mvn test (JUnit 5 on the slug rules, query parsing and JSON escaping) · ./smoke.sh https://... against a deployment.

Run locally

Use JDK 21 and Maven 3.9. From java/slug-maven:

mvn test
mvn package
PORT=8080 java -jar target/slug-maven.jar

Open http://localhost:8080, or call the API directly:

curl 'http://localhost:8080/api/slug?text=Cr%C3%A8me%20Br%C3%BBl%C3%A9e'

Deploy and verify

Follow the deployment walkthrough. Deploy this folder, pom.xml, src/ and yeeted.yaml, with no database and no Dockerfile. Do not upload target/; the build runs on Yeeted. The manifest selects port 8080 and /healthz. A first Maven build downloads its plugins, so allow a few minutes and follow the deployment status.

sh smoke.sh "$PREVIEW_URL"

The script checks the health endpoint, the page, two slugs (one with accents), and that a blank request is refused with 400.

What to change before real use

The generated image copies target/*.jar, so the build must produce exactly one jar there: keep finalName and do not add a second packaging plugin (a shaded or sources jar beside the main one breaks the copy). Add a framework or a library through pom.xml as usual; anything the app needs at runtime has to be inside that one jar, for example with the shade or Spring Boot plugin configured to replace the plain jar.

All examples · Deploy an example