Working with environments
Hosty supports unlimited amount of development environments (as long as it does not exceed the resource limit set by hosting administrators). Developers are welcome create, update and destroy the development environments at their own preference.
Development environments are always created from the latest production backups. For the database Hosty uses latest partial database dump that excludes PII (personal identifiable information). Developers are responsible for configuration of the database tables to exclude content from when making a partial database backup (see excludeTablesFromImportOnDevEnvs config on the Project configuration page). It's recommended to exclude both PII and other content not relevant for development environments (i.e. cache tables) to speed up the new environment creation process.
Hosty uses a reserved name for the production environment: production. When this environment name is used, Hosty knows to deploy the application to an isolated production cluster, create at least 2 replicas of the environment, use it for backups and so on.
Environment names can be arbitrary, as long as they match validation criteria:
- Does not exceed 24 chars
- Contains only alphanumerical chars and "-" or "_".
We recommend matching environment names to the Git branches, as it seems easier to keep track of the created environments. However, it is not mandatory.
The environment creation (same as environment update) consists of 3 steps:
Building the project dependencies and making the codebase ready to run the application. Developers are responsible for this step, because it should happen outside of the Hosty's ecosystem. It usually involve building project dependendies using dependencies managers and therefore calling commands like composer install, npm install and so on.
Pushing the built code to the Hosty infrastructure. On this step, the code is added to a clean Docker image (based on Linux Alpine) and is pushed to the images repository. We highly recommend making sure that the code does not contains cache, user generated content or other assets not relevant to the application runtime execution. Otherwise, the time to push the codebase to the hosting can be significantly increased. The recommended solution is to use the CI/CD platforms (like CircleCI, Github Actions, etc) where it creates a clean environment, downloads git repository, builds the project dependencies and then pushes the prepared codebase to the infrastructure. The command to do this is:
Creating a new environnment. The last step is to actually create an environment for the prepared codebase. It can be done by calling the following command:
It usually takes a couple of minutes, depending on the size of the project's backup.
Optionally, you may want to run post deploy commands. It can be done using the following command:
As the last step, you may want to list environment domains to access the built environment. To get this information, run:
Environment deletion permanently destroys the environment's database and file assets (user generated content) without an ability to restore.
To delete an environment, you can use the following command:
If you're deleting an environment with the plan to recreate it, we recommend giving it a few minutes to let all the systems complete their deletion routine before calling a command to create a new environment with the same name.