Dockerfile.vercel is not detected in standalone Pro project

We have a standalone Java HTTP validator project on Vercel Pro. Root Directory is services/pint-ae-validator; Dockerfile.vercel is directly in that directory; Build Command is Auto; no --prebuilt deployment is used.

Git deployments complete in ~27ms with Running "vercel build", create no OCI image/function, and /healthz returns 404. Re-deploying without cache produces the same result.

Vercel documentation says this setup should auto-build the image and deploy it as a container function. Is there a known beta limitation or configuration requirement affecting Git deployments with a nested Root Directory?

No secrets or customer data are involved. I can provide anonymised deployment IDs/log excerpts. Anonymised deployment log excerpt:

[build] Cloning completed Running "vercel build" Vercel CLI [version redacted] Detected framework: Other Build completed in approximately 27 seconds Deployment marked Ready

[observed result] GET /healthz → 404 NOT_FOUND

[expected result] Dockerfile.vercel should be detected, an OCI image built/pushed, and the HTTP server routed as a Container Function.

[relevant project configuration]

Plan: Pro
Separate standalone project, not the main application
Root Directory: services/pint-ae-validator
services/pint-ae-validator/Dockerfile.vercel exists in Git with exact casing
Build Command: Auto / no override
Deployment source: connected Git branch
No CLI --prebuilt deployment
Redeployed with build cache disabled; same result
No environment variables, customer data, or secrets are needed to reproduce /healthz

There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes.

https://community.vercel.com/t/debugging-404-errors/437

Vercel Community

Debugging 404 Errors

Sometimes things don’t go as expected when deploying a website. If you see a 404 on your site, that means the page or resource couldn’t be found. There are...

A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Update — Container preset is now configured, but the runtime still fails before application output

Current standalone Pro-project configuration:

Framework Preset: Container
Root Directory: services/pint-ae-validator
Dockerfile.vercel directly in that root directory
Build Command / Output Directory: Auto
Production environment variables configured, including PORT=8080
fresh deployment builds and pushes the OCI image successfully; deployment reports Ready

However, GET /healthz now returns: 500 INTERNAL_FUNCTION_INVOCATION_FAILED

This happens on the deployment URL and assigned project domain. Runtime logs show only Vercel request records; there is no container stdout, stderr, Java exception, or function-start output.

To isolate application startup, I added safe fixed startup markers before configuration, bundle-manifest loading, PHIVE registry initialization, and HTTP listener creation. Local real-container tests pass:

/healthz returns 200
official PINT-AE positive/negative fixture gate passes
all four startup markers appear locally

On Vercel, none of those markers appear. This suggests the container is failing before the Java process can emit output, or the beta runtime is suppressing all child-process logs.

Can a Vercel team/contributor member confirm:

whether a Java 21 java -jar OCI image needs any additional Vercel Container Function setting;
whether ENTRYPOINT, a non-root container user, or port 8080 is unsupported in this beta;
how to obtain the underlying startup error for INTERNAL_FUNCTION_INVOCATION_FAILED when no stdout/stderr is surfaced?

Thanks,

Update: we completed a clean Preview isolation test.

Deployment: dpl_CztybBtvu1RpXbc6eovkmRwfGQYn Commit: 6ddfa27247b423d24c87c2d8db7fd162b0304db1 Framework: Container Root Directory: services/pint-ae-validator Preview PORT: 8080 confirmed

The OCI image builds and pushes to Vercel Container Registry successfully, and the deployment is marked Ready. The Java service now opens its HTTP listener before any secret, manifest, or PHIVE validator initialization. Until initialization completes it returns only a safe 503; validation remains fail-closed.

Despite that, /healthz returns Vercel’s bare INTERNAL_FUNCTION_INVOCATION_FAILED (500), never the service’s 503 or 200 response.

For this exact deployment, Runtime Logs show only empty platform request records—no container stdout, stderr, startup diagnostic, or internal exception.

Can a Vercel team member inspect why this Container Images Preview deployment cannot start or connect to its HTTP process, and advise whether there is a known limitation with Java 21 / eclipse-temurin:21-jre-jammy / non-root USER / ENTRYPOINT-based containers?

Does Container Images beta run custom images with a read-only root filesystem, and is /tmp writable for a non-root container using eclipse-temurin:21-jre-jammy with a direct Java ENTRYPOINT?

Solved: Java Container Function on Vercel returned 500 because Vercel’s injected wrapper could not find java

I’m posting the final resolution in case it helps others deploying a Java OCI image with Dockerfile.vercel.

Symptoms

Vercel project used Dockerfile.vercel in a monorepo subdirectory.
Image built successfully and was pushed to Vercel Container Registry.
Deployment showed Ready.
Every request, including /healthz, returned:

500 INTERNAL_SERVER_ERROR
FUNCTION_INVOCATION_FAILED

Initially, runtime logs appeared empty, which made this look like a port, Java, PHIVE, secret, or container-runtime issue.

Initial project configuration

The service project needed these settings:

Framework Preset: Container
Root Directory: services/pint-ae-validator
Build / Output / Install Command overrides: disabled
Container server listens on PORT=8080
EXPOSE 8080

Manually selecting Container was necessary because Dockerfile auto-detection did not initially select it.

What was ruled out

The following were not the cause:

Java application logic
PHIVE / XML validation initialization
HMAC configuration
port 8080
binding to localhost
non-root container user
the Java 21 Temurin image itself

A minimal Java 21 HTTP probe using the same non-root user, port 8080, and CMD also crashed on Vercel despite working locally.

Actual root cause

Request-specific Vercel runtime logs eventually showed:

/__cacert_entrypoint.sh: line 114: exec: java: not found

Vercel injects a certificate-entrypoint wrapper before starting the container command. In this runtime path, the wrapper did not preserve the Eclipse Temurin image’s normal PATH.

The Java binary exists in the image at:

/opt/java/openjdk/bin/java

but a Docker command using only java could not be resolved by the wrapper.

Fix

Replace the bare Java invocation with the absolute binary path, using CMD:

FROM eclipse-temurin:21-jre-jammy

# … application files, non-root user, ENV PORT, EXPOSE …

CMD ["/opt/java/openjdk/bin/java", "-XX:MaxRAMPercentage=70", "-jar", "/app/pint-ae-validator.jar"]

Do not assume this exact path for every Java base image—confirm it locally first:

docker run --rm --entrypoint sh eclipse-temurin:21-jre-jammy \
  -lc 'command -v java && readlink -f "$(command -v java)"'

For Eclipse Temurin 21 JRE Jammy, it returns:

/opt/java/openjdk/bin/java

Verified outcome

After redeploying with the absolute Java path, the real validator returned:

{
  "ok": true,
  "service": "pint-ae-validator",
  "profile": "pint_bis_billing_ae@1.0.4",
  "bundle_sha256": "f6db45abe0ad3f198cc16a20402516943ff295ee8d54aec0c62ca9a354b08be6"
}

The service runs as a non-root user and on port 8080. No Cloud Run migration, new hosting service, root-user workaround, or Java-runtime change was required.

Suggested documentation improvement

It would help if the Container Images documentation noted:

Container auto-detection may require manually setting Framework Preset to Container.
Vercel’s injected certificate entrypoint can affect PATH-based commands.
For Java images, use an absolute Java binary path if logs show exec: java: not found.

Update: same container source passes Preview but fails on the project’s main/Production deployment path

We have now isolated two separate issues in our standalone Java validator container project.

Project setup remains unchanged:

Pro team
Framework Preset: Container
Root Directory: services/pint-ae-validator
Dockerfile.vercel in that root
no build/output/install overrides
container resource /container in iad1
HTTP server uses configured PORT=8080

First issue — resolved in Preview:

A fresh container previously failed to load Java’s libjvm.so. We added a minimal non-root launcher which explicitly sets JAVA_HOME and LD_LIBRARY_PATH, verifies the library is readable, then execs the unchanged Java command.

The automatic PR Preview deployment for this repaired source is healthy:

Deployment: dpl_CgGZjg7QRevgCrjZYwW5YSLCYTXs
Commit: 819c3526
/healthz: HTTP 200
Trace: Mumbai edge → routed to iad1 → Function Invocation /container
Runtime stages emitted normally: configuration → bundle_manifest → rules_bundle_manifest → phive_registry → http_listener

The exact same validator-source tree was squash-merged to main as commit:

37301082a97785e3cfb4be491f6585bec492ee86

Second issue — still failing only on the main/Production deployment path of this staging validator project:

Vercel automatically created a deployment for that merged main commit:

Deployment: dpl_haG6rqPJSEVzYWTRSUqsAfwMUEPa
Commit: 37301082
Environment: Production (of our dedicated staging-validator project)
Build: Ready, 55 seconds
Immutable URL /healthz: 500 INTERNAL_FUNCTION_INVOCATION_FAILED

The failed request trace is materially different from the passing Preview:

Mumbai edge → Firewall Allowed → trace stops

There is no route to iad1, no Function Invocation /container, no container stdout/stderr, and no application startup stages.

The staging custom alias remains pinned to an older known-good immutable deployment; no failed build has been promoted or served to normal staging users.

This now appears to be a release-environment activation/routing issue for fresh Container deployments, independent from the Java launcher issue that Preview successfully exercised.

Questions for Vercel engineering:

Why can a byte-identical container source run successfully in Preview but a Git-triggered main/Production deployment marked Ready fail before Function Invocation?
Can you inspect and compare internal route/activation metadata for:
- healthy Preview dpl_CgGZjg7QRevgCrjZYwW5YSLCYTXs
- failing main deployment dpl_haG6rqPJSEVzYWTRSUqsAfwMUEPa
Is there a supported user-side way to repair or re-stage the Container Function activation without another source rewrite or alias movement?
Is this a current limitation/known issue for Container Images in the Production environment of a dedicated staging project?

Resolved: explicit routing for a Vercel Container service deployed from a monorepo root directory.

We had a standalone Java PINT-AE validator deployed as a Vercel Container project with:

Root Directory: services/pint-ae-validator
Framework: Container
Dockerfile.vercel in that root

Preview deployments reached the container, but Git-triggered Production-target deployments built the container while public paths such as /healthz were handled as static and never invoked it.

The fix was to make the container service and public routing explicit inside the Vercel project root:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "services": {
    "validator": {
      "root": ".",
      "entrypoint": "Dockerfile.vercel",
      "runtime": "container"
    }
  },
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": {
        "service": "validator"
      }
    }
  ]
}


Important: this vercel.json belongs inside the standalone service root, not at the monorepo root.
Verification after release:
- /healthz repeatedly returns 200 with the real validator JSON payload.
- Vercel runtime logs show serverless invocation in iad1 and the Java validator startup stages.
- / now returns the application’s expected 404, which confirms the request reaches the container rather than static hosting.
- No Java, Dockerfile, port, HMAC, PHIVE, secret, or alias changes were needed.
The key lesson: a built /container function is not enough by itself—public routing must also point at that service.

This topic is closed. It no longer accepts new replies.

Update: same container source passes Preview but fails on the project’s main/Production deployment path

We have now isolated two separate issues in our standalone Java validator container project.

Project setup remains unchanged:

Pro team
Framework Preset: Container
Root Directory: services/pint-ae-validator
Dockerfile.vercel in that root
no build/output/install overrides
container resource /container in iad1
HTTP server uses configured PORT=8080

First issue — resolved in Preview:

The automatic PR Preview deployment for this repaired source is healthy:

Deployment: dpl_CgGZjg7QRevgCrjZYwW5YSLCYTXs
Commit: 819c3526
/healthz: HTTP 200
Trace: Mumbai edge → routed to iad1 → Function Invocation /container
Runtime stages emitted normally: configuration → bundle_manifest → rules_bundle_manifest → phive_registry → http_listener

The exact same validator-source tree was squash-merged to main as commit:

37301082a97785e3cfb4be491f6585bec492ee86

Second issue — still failing only on the main/Production deployment path of this staging validator project:

Vercel automatically created a deployment for that merged main commit:

Deployment: dpl_haG6rqPJSEVzYWTRSUqsAfwMUEPa
Commit: 37301082
Environment: Production (of our dedicated staging-validator project)
Build: Ready, 55 seconds
Immutable URL /healthz: 500 INTERNAL_FUNCTION_INVOCATION_FAILED

The failed request trace is materially different from the passing Preview:

Mumbai edge → Firewall Allowed → trace stops

There is no route to iad1, no Function Invocation /container, no container stdout/stderr, and no application startup stages.

The staging custom alias remains pinned to an older known-good immutable deployment; no failed build has been promoted or served to normal staging users.

This now appears to be a release-environment activation/routing issue for fresh Container deployments, independent from the Java launcher issue that Preview successfully exercised.

Questions for Vercel engineering:

Why can a byte-identical container source run successfully in Preview but a Git-triggered main/Production deployment marked Ready fail before Function Invocation?
Can you inspect and compare internal route/activation metadata for:
- healthy Preview dpl_CgGZjg7QRevgCrjZYwW5YSLCYTXs
- failing main deployment dpl_haG6rqPJSEVzYWTRSUqsAfwMUEPa
Is there a supported user-side way to repair or re-stage the Container Function activation without another source rewrite or alias movement?
Is this a current limitation/known issue for Container Images in the Production environment of a dedicated staging project?

{ "$schema": "https://openapi.vercel.sh/vercel.json", "services": { "validator": { "root": ".", "entrypoint": "Dockerfile.vercel", "runtime": "container" } }, "rewrites": [ { "source": "/(.*)", "destination": { "service": "validator" } } ] } Important: this vercel.json belongs inside the standalone service root, not at the monorepo root. Verification after release: - /healthz repeatedly returns 200 with the real validator JSON payload. - Vercel runtime logs show serverless invocation in iad1 and the Java validator startup stages. - / now returns the application’s expected 404, which confirms the request reaches the container rather than static hosting. - No Java, Dockerfile, port, HMAC, PHIVE, secret, or alias changes were needed. The key lesson: a built /container function is not enough by itself—public routing must also point at that service.