Within the context of Kinsta 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.
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 similar to a Cron job, where a specified command is executed at a set time or interval.
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.
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 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.
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.