When deploying an application, if there is an issue with deployment, you may see one of the following errors:
Your application experienced a rollout error. Check our documentation, and if you continue to experience problems, contact our support team.
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 application runtime logs to identify any error messages. The error messages can help you to 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.13Start 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 a couple of places in MyKinsta:
- Processes > Runtime processes > Web process.
- Or Deployments > History, select a deployment to view the details, then click Rollout process under Deployment progress.
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 your application’s Settings.
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 Settings > Environment variables.
Confirm that the correct environment variables exist and contain valid values. There are a couple of important things to keep in mind when creating and checking environment variables:
- Commas are interpreted as delimiters by the rollout process, so they cannot be used in environment variables.
- Depending on when they are available during deployment, parentheses can cause the build or rollout process to fail, and they cannot be used in environment variables.
- Each key must be unique, and a key can only be added once.
- Unescaped double quotes are either disregarded or will cause the rollout process to fail.
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. If your application exposes any ports, you must use 8080.
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.