Within the context of Kinsta’s Application Hosting, an application is a set of instructions executed by a server to perform one or more tasks. Our current infrastructure is designed to serve and support the deployment of applications with a server behind the application.
One of Kinsta’s Hosting Services. It is a Platform as a Service (PaaS) that provides you with the tools you need to deploy applications from a Git repository.
The location where built images are stored. Each application has a single image that can be turned into a container.
When Automatic deployment on commit is enabled, and a new commit is made to the default branch of your Git repository, a new version of the application will be deployed from MyKinsta.
A process that runs in the background, separate from the main application, and is inaccessible from the internet. Used to keep long-running processes separate from the main application to help maintain a good user experience. Not meant to be run as a one-time job that finishes after a certain amount of time. If a background process finishes after it completes its job, the pod will shut down, restart itself, and repeat the process. For a process that finishes after completing its job, use a cron job process.
The time it takes for an image to be built from an application’s source code. Builds are performed on machines specifically designated for building images. Multiple build machine sizes exist, and you can choose between these machines depending on the resources required to build the application. Build time is billed at different rates, separate from your application’s hosting pods.
Buildpacks are scripts that run when an application is deployed. They are used to install dependencies for your application and configure your environment.
A commit records changes to one or more files in a Git branch and assigns a unique ID (called an SHA or hash) that identifies the specific changes and when those changes are made.
Concurrent connections are connections that are happening simultaneously (i.e. at the same time). While there is a relationship between concurrent connections and users, it is not always a direct 1:1 relationship. One user can spawn multiple connections, depending on their actions and depending on the application’s code.
An application’s maximum concurrent connections depends on a number of factors, including its code, usage patterns of users, etc. To calculate this number, you need to know your application’s resource consumption. There are a number of load testing tools you can use to send concurrent connections to the application and see the resource usage during that time:
Connections are how applications communicate.
An External connection allows your database to communicate with an external application. This would be used in a situation where you are hosting only your database with us but not the frontend of your application. Because an external connection makes an internet round-trip, it is much slower than an internal connection.
An Internal connection stays within our network and is thus much faster and more secure. We recommend this method if you host both your frontend and your database with Kinsta.
A process you can schedule at a specific interval for your application so you can automate repetitive tasks. The process only launches based on the configured timing and shuts down after finishing the required operation.
A collection of data stored in an organized manner so it can be retrieved or updated efficiently.
A deployment is a rebuild of your application in a new container, usually done after updating your application’s code, but can be configured to happen automatically (see automatic deployment above). The deployment invokes any buildpacks and applies any environmental variables each time the application is deployed.
Variables such as API keys, database connection details, or other configuration values or secrets. By using environment variables, you can avoid putting this information in your code as cleartext (unencrypted text).
A Git repository is where your application code and historical versions of that code are saved.
See Pod below.
Runtime logs from the application build process.
Persistent storage (aka persistent volume) retains data after an application is shut down or restarted. It’s used for data that needs to be preserved across multiple sessions or devices, such as session data, user preferences, and cached content.
Stateful applications use persistent storage to request storage volume from an underlying storage system. The storage volume is mounted as a file system which allows the application to read or write to the storage device as if it were a local disk.
A Pod is a container that runs a Process. Each Pod has a Pod Size that defines the resources available to the Pod in terms of CPU and RAM.
The smallest unit you can deploy in our Application Hosting. While this is usually a well-defined item like a frontend for a web application, it could also serve as the backend for a mobile application. While it is usually well defined, it’s up to you to decide what you want to run within a Pod or what constitutes a process. It’s possible to run multiple processes within a pod, but the Pod’s resources will be split up amongst those processes.