Failed Deployment

When you deploy your application, you may experience an error during the build or rollout phase that causes the deployment to fail. You should always check the individual Deployment logs and Runtime logs, as they may indicate the reason for the failed deployment. This article explains how to troubleshoot specific deployment errors; if your issue still occurs after following these steps, refer to our general troubleshooting steps.

Build process failed – No buildpack groups passed detection

When deploying an application using Buildpacks, if there is an issue detecting your application’s buildpack during the build process, you may see the following error in the Deployment logs.

Build process failed
Unknown build fail type

Open the Deployment logs and look for errors similar to the following:

===> DETECTING
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 20

These errors occur when there isn’t enough information to correctly detect the type of application. This is usually caused by one of the following:

• The Git repository doesn’t contain all the files needed for the application.
• Something within the code or settings causes an incorrect buildpack to be selected.
• The build path is incorrect.

Git repository

Check your repository to ensure all the correct files have been pushed into the repository for your application.

Buildpack

If you choose Set up container image automatically when you add your application, we use a buildpack to automatically determine and set up a container for your application. If your application requires an additional buildpack, you can add additional buildpacks on your application’s Settings > Build page.

When using buildpacks, you must also ensure the correct language version is in your application’s files. For more details, see our documentation on specifying a language version for Nixpacks or Buildpacks.

Build path

The build path is where the files to build your application are located in the repository. Usually, this is the repository root, and you do not have to set a build path when adding your application.

If your application has a different build path, you can set that when you add the application, or you can change it in Settings (Settings > Build > Change environment). For example, if your application needs to be built from a subdirectory named app, enter that subdirectory path as /app in the Build path field.

Failed build because process exited too early

When deploying an application, if there is an issue with the build process, you may see the following error:

The build failed because the process exited too early. This probably means the system ran out of memory or someone called kill -9 on the process.

This is usually caused by insufficient system memory in the build machine for the application.

To resolve this error, increase the size of your application’s build machine. Go to Settings > Build > Update resource, choose a larger build machine and click Update resource again to confirm the change.

Failed build due to Buildpack version

When deploying an application using Buildpacks, you may receive an error regarding the Buildpack version, such as:

Please switch to one of our newer ‘heroku/builder:*’ builder images, such as ‘heroku/builder:22’

This may be due to an updated build configuration in MyKinsta. To resolve this:

1. In MyKinsta, click Applications > app name > Processes > edit the Web process > for Laravel applications, enter the following start command: heroku-php-apache2 /public for all other PHP applications, remove the Start command.
2. Click Continue > Confirm.
3. Click Deployments > Deploy now.

Failed rollout

When deploying an application, if there is an issue with deployment, you may see one of the following errors:

Build process failed
Unknown build fail type

If the rollout process fails immediately, or if the build process fails, no pods are created, and runtime logs do not exist, an incorrect start command in the web process is most often the cause (or an incorrect ENTRYPOINT in the Dockerfile if your application is built from a Dockerfile).

If the rollout process runs for a minute or two and then fails, this usually means the pods were created, but something went wrong, and the process stopped. In this case, you should check the deployment runtime logs to identify any error messages. The error messages can help you identify bugs in the application’s code so you can debug the issue.

If you cannot identify the issue, check the following, and if the issue persists, contact our Support team.

Git repository

Check your repository to ensure all the correct files have been pushed into the repository for your application.

Language

When you add your application and choose to use Nixpacks or Buildpacks to create your application’s container image, we automatically determine and set up a container for your application. When using Nixpacks or Buildpacks, if you do not want the default or latest available version of the language to be used, you must set the language version in your application’s files. For more details, see our documentation on specifying a language version for Buildpacks or specifying a language version for Nixpacks.

Additionally, If you deploy a PHP or Python application with Nixpacks and the rollout fails when the container image is built, this is most likely due to a missing language version in the application’s code, particularly if the deployment works with Buildpacks but not with Nixpacks. Check the following to make sure the language version is set:

PHP

If there is a composer.json file in your repository, it must contain the require key with the PHP version, like the following:

{
  "require": {
    "php": "~8.1.0"
  }
}

Python

To specify your Python version, include the following in your application’s runtime.txt file:

python-3.10.13

Start command or ENTRYPOINT

The Start command for the web process starts your application. If this is incorrect, the application will not run. You can check the command in Processes > Runtime processes > Web process.

If your application uses a Dockerfile to set up your container image, you must specify the ENTRYPOINT in the Dockerfile to run a container. For more information about how to specify your application’s ENTRYPOINT, see the Dockerfile reference.

For more details about what command to use based on your application’s language, see the examples provided in our Application Start Command documentation.

Build path or Dockerfile context

When you add your application, you choose to either set up the container image automatically with a Nixpack or a Buildpack or use a Dockerfile to set up the container image.

• Build path: This only applies to Nixpacks and Buildpacks. This is the path in the repository to the files required to build the application. Most applications are built from the repository root, and the Build path defaults to this (.). If you have a different build path, specify it here. For example, if your application needs to be built from a subdirectory (e.g. app), enter that subdirectory path in the Build path field: app. This is also useful if you have a monorepo.
• Context: This only applies to Dockerfiles. This is the path in the repository we need access to so we can build your application. Most applications are built from the repository root, and you can enter the repository root (.) in the Context field. If your application needs to be built from a subdirectory (e.g. app), enter that subdirectory path in the Context field: app.

You can view and change the Build path or Dockerfile Context in Settings > Build > Change environment.

Environment variables

Environment variables feed your application information from outside of the running of that application. An incorrect environment variable may prevent your application from running. You can check your environment variables in Environment variables.

Confirm that the correct environment variables exist and contain valid values. There are a few important things to keep in mind when creating and checking environment variables:

• Each key must be unique, and a key can only be added once.
• Parentheses can cause the build or rollout process to fail, depending on when they are available during deployment. They cannot be used in environment variables.
• Unescaped commas are interpreted as delimiters by the rollout process, so they cannot be used in environment variables. If you need to use a comma in your environment variable value, you must escape it with a backslash (\).
• Unescaped double quotes are either disregarded or will cause the rollout process to fail. If you need to use double quotes in your environment variable value, you must escape them with a backslash (\).

Internal connections and the build process

Internal connections are only available during runtime; they are not available during the build process.

If your application tries to connect to a database using an internal connection during the build process, this causes an error that says the database is not running, which makes the build fail. This is expected because the internal connection is not live during the build; it can only be used during runtime.

There are a couple of ways to work around this.

Option 1: Move the logic that connects to the database from the application’s build command to the start command. For example: if you have a command like prisma migrate in the build process and move that command to the start command, your application will only access the database during runtime, and the build will be successful.

Option 2: Add separate environment variables as needed for the database connection, one available for the build process, and the other only for runtime. The keys can be the same (e.g. DB_CONNECTION_URL) as long as one is only available during the build process and the other is only available during runtime. Use the database’s External connection details (Databases > dbname > Info > External connections) for the values of any variables to be used in the build process.

Port

For Application Hosting, only ports 80 and 443 are open. You can change the port your application’s web process uses when you add the application or within Networking > Edit port.

Invalid package name

An invalid package name in package.json can cause an error. For example, do not use “js” or “node” in the name. For more details, see the specifics of npm’s package.json handling in the npm Docs.