Forum

Zeabur supports multiple Dockerfiles in the same repo; they just weren't recognized because the default service naming didn't match. There are two ways to specify them:

Method 1: Name the Dockerfile after the service

Name your Dockerfile in either of the following formats, and Zeabur will automatically match it:

• [service-name].Dockerfile, e.g., admin.Dockerfile
• Dockerfile.[service-name], e.g., Dockerfile.admin

The naming format of Dockerfile.admin / Dockerfile.migrate / Dockerfile.proxy in your screenshot is correct. As long as you create the corresponding services named admin / migrate / proxy on Zeabur, they will automatically match the respective Dockerfiles.

Method 2: Specify via environment variables or zbpack.json

Add the following to the service's environment variables:

ZBPACK_DOCKERFILE_NAME=Dockerfile.admin

Or place a zbpack.json in the root directory of your repo:

{
 "dockerfile": {
 "name": "admin"
 }
}

Redeploy after configuring.

Full documentation: https://zeabur.com/docs/zh-TW/deploy/dockerfile

You're welcome! Good luck 🙏 Please let us know the results after you've tried it. If you're still stuck, please take a screenshot of the Settings page and share it with us so we can take a look.

Sorry, the previous instruction was incorrect. The ZBPACK_DOCKERFILE_NAME variable only accepts the suffix—zbpack automatically constructs it as Dockerfile.<value> or <value>.Dockerfile for matching (official documentation example: ZBPACK_DOCKERFILE_NAME=storage corresponds to Dockerfile.storage).

If you set it to Dockerfile.admin, zbpack will actually look for Dockerfile.Dockerfile.admin, which naturally won't be found. Furthermore, once this variable is set, the default "auto-match by service name" logic is overridden and will not fall back.

You can choose one of the following two fixes:

1. Delete this environment variable entirely—since the service name is admin, zbpack will automatically match Dockerfile.admin in the root directory.
2. Change the value to just the suffix: ZBPACK_DOCKERFILE_NAME=admin

After updating the settings, just trigger a redeploy. If you need further assistance, please reply.

I checked your failed admin service deployment record from 5/8 and found the root cause: the environment variable set for that service was ZBPACK_DOCKERFILE_NAME = Dockerfile.admin (the full filename). This is the exact pitfall I mentioned in my last reply: this variable only accepts the suffix, not the full filename. When zbpack receives Dockerfile.admin, it tries to construct Dockerfile.Dockerfile.admin, which naturally doesn't exist, so it falls back to nodejs. Therefore, the failure on 5/8 had little to do with the repository itself; it was just an incorrect environment variable.

In your screenshot today, you've changed the value to admin, which is correct. There are only two remaining possibilities:

1. There is actually no Dockerfile.admin in the root directory of the current main branch—the file tree screenshot you provided earlier looks like a JetBrains IDE Project panel, which might not reflect the actual state on GitHub. Please open the GitHub website directly, switch to the main branch, and check if the Dockerfile.admin file exists in the root directory (a screenshot including the URL bar would be best).
2. The environment variables were not actually passed to zbpack during the 'Preview' stage of creating a new service—in this case, the preview will always show nodejs, but the actual deployment uses a different code path that passes your defined service name as SubmoduleName to zbpack. Theoretically, even without the environment variable, as long as the service is named admin and Dockerfile.admin is in the root directory, it should match automatically. In other words, the preview might show nodejs, but the actual deployment might be docker.

The fastest verification process:

• First, go to the GitHub website to confirm that Dockerfile.admin is truly in the root of the main branch (this is critical, step one).
• If it is there, go ahead and create the service (name it admin, keep the environment variable ZBPACK_DOCKERFILE_NAME=admin), click deploy, and check the planType of the actual Deployment.
• If the actual deployment is still nodejs, please reply and let us know, and we can confirm if it's a platform-level issue and handle it for you.