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 what data is used to create new envs? 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 docid\ lkb3t2ovil49dtus 7u1v 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 naming environments 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 building and deploying envirionments 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 hosty build push \<environmentname> \# for example hosty build push stage 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 hosty deploy \<environmentname> \# for example hosty deploy stage 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 hosty exec \<environmentname> command="\<command>" \# for example hosty exec stage command="drush cache rebuild" command="drush deploy" as the last step, you may want to list environment domains to access the built environment to get this information, run hosty domains \<environmentname> \# for example hosty domains stage deleting an environment 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 hosty delete \<environmentname> \# for example hosty delete stage 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