A staging site is a copy of a site on the same server that deploys another branch of the same repository, on an address of its own. Use it to try a branch, such as develop or staging, before it goes live: every push to that branch deploys the staging site, and only the staging site.
Staging sites are real sites. Each has its own pages (deployments, environment, domains, logs and so on), its own directory on the server, its own deploy key and its own deploy URL. They are listed on the Staging page of the site they stage, and under it on the server's Sites page.
Create a staging site
- Open the site and click Staging in its sidebar.
- Click New staging site.
- Choose the Branch. With a Git connection, the repository's branches are suggested (the branch the site itself deploys is left out); you can also type a branch you will push later.
- Choose the address:
- an Address on
on-deploy.link, filled in with a generated name that starts withstaging-(when generated addresses are available). It gets HTTPS by itself once the address resolves; or - click Use a custom domain and enter a Domain, such as
staging.example.com. When the domain is in a zone of one of your DNS integrations, you see the records Vimonto Deploy will make, the same way as when you add a domain. Nowww.record is made for a staging domain.
- an Address on
- Leave Copy the .env on to start from the site's
.env(shown when the site has one). - Leave Deploy on every push on to deploy the staging site on every push to its branch (shown for sites with a Git connection).
- Click Create staging site.
The staging site is set up as a background task, like a new site, and its first deploy starts when the setup is done.
Which database does a staging site use?
Never the live one. On a server with a database, every staging site gets a new, empty database and a user of its own, named after its address (for example staging_example_com). Run your migrations and seeders on it: php artisan migrate --force in its deploy script only ever changes the staging database.
On a server without a database (for example a web server whose database runs on a separate database server), the staging site gets no database settings: the copied .env has empty DB_DATABASE, DB_USERNAME and DB_PASSWORD. Create a database for staging and fill them in on its Environment page, never with the live database's details.
What does a staging site get?
A staging site is made with Clone site, on the same server, with these differences:
| Staging site | |
|---|---|
| Repository, Git connection, build settings, deploy script, notifications, redirects and security rules | Copied from the site |
| Branch | The branch you chose |
| Address and directory on the server | Its own |
| Deploy key, deploy URL and push webhook | Its own |
| Database | Its own new database and user (never the site's database) |
| Certificates, queue workers and processes, site features, files the app stored | Not copied |
The .env of a staging site
With Copy the .env on, the staging site gets the site's .env with:
APP_URLset to the staging address;APP_ENV=staging;- the
DB_CONNECTION,DB_HOST,DB_PORT,DB_DATABASE,DB_USERNAMEandDB_PASSWORDof its own database, or empty database settings on a server without a database.
Everything else, such as mail, cache and queue settings, stays the same as on the live site. Change those on the staging site's Environment page if it needs its own.
With Copy the .env off, the staging site gets a fresh .env, as a new site does, with APP_ENV=staging.
How pushes are deployed
The site and each of its staging sites have their own webhook at your Git host, each with its own deploy URL. A push reaches all of them, and each one only deploys when the push is to its own branch:
- a push to
maindeploys the site that followsmain; - a push to
developdeploys the staging site that followsdevelop.
The other webhooks answer that the push was not to their branch, and nothing else happens. Switch Deploy on every push for a staging site on or off later on its Deployments page.
Deploy, open and delete staging sites
The Staging page lists every staging site of the site, with its branch, whether it deploys on every push, and its last deployment. For each one you can:
- click Deploy now to deploy its branch right away;
- click Open site to open its address in a new tab;
- click its address to go to the staging site's own pages;
- click Delete, type its address and click Delete staging site to remove it.
Deleting a staging site works like deleting a site: it is removed from the server with its releases, .env, workers and certificates, and Vimonto Deploy removes the DNS records it made for it and its deploy key and webhook at your Git host. Its database is kept; delete it on the server's Databases page.
The site's header shows how many staging sites it has; a staging site's header shows Staging of with a link back to its site.
Who can create staging sites?
Every member can see staging sites. Creating, deploying and deleting them needs permission to manage sites, which owners, admins, managers and developers have. Staging sites are on the same server as their site, so members who can open the site can open its staging sites.
Frequently asked questions
Can every site have staging sites?
Sites with a repository can. WordPress, phpMyAdmin and load-balanced sites cannot, and a staging site cannot have staging sites of its own.
What happens to staging sites when I delete the site?
They stay, as sites of their own. Delete them first on the Staging page if you no longer need them.
Can I put a staging site on another server?
Not from the Staging page: staging sites are on the server of their site. Use Clone site to make a copy on another server.
Why is the staging site's branch not suggested?
Branches are suggested for sites with a Git connection. For a site with a Git URL only, type the branch name.