Building · ContractsDeploy · Release · Go live
Deployment
Deployment is putting a newly built website or your latest edits onto the real address so customers can see them.
It's the moment a finished dish leaves the kitchen for the customer's table.
A little more detail
You don't only deploy at the first launch. Even if you change a single price, it has to be deployed again before customers see it.
Right after a deployment, your browser may still remember the old page, so it can look unchanged. Refresh, or check again a little later.
If something goes wrong, you need to be able to roll back to the previous version right away. That's why a backup and a preview check go hand in hand with every deployment.
What are the steps to deploy a website?
Deployment usually goes in this order: "edit → check the preview → approve → push to the live address → check after launch." Most hosting services used today first upload changes to a preview URL, then switch them over to the live address once checking is done.
Very small changes, like fixing a single typo, are sometimes deployed straight away without a preview check. But for anything tied to promises you make to customers, like prices, bookings and payments, it's safer to look at the preview once before it goes live.
How long a deployment takes depends on the website's size and how it's hosted. Small websites often finish within a few minutes, but keep in mind that until you're told it's done, you may not be seeing the updated screens yet.
- 01You request the changes you want.
- 02The developer makes the changes and uploads them to a preview URL.
- 03You check the changes in the preview and approve them.
- 04The developer deploys to the live address. This also bundles the code into files for the live site (the build).
- 05Once deployment is done, check the changes and the booking and inquiry buttons again on the live address.
- 06Keep a record of what was changed and when.
What's the difference between deployment, hosting and a domain?
The domain is your business's address, hosting is the spot where your website files sit, and deployment is the act of putting new files in that spot. If any one of the three has a problem, customers can't see your website properly.
When you switch agencies or move hosting, all three move together, which makes it easy to get confused. Even if you keep the domain and only move the hosting, customers will only see the new site after you deploy to the new hosting and change the connection so the domain points to the new spot.
If you miss a domain renewal, the address won't open no matter how well the site was deployed. Also check when your domain expires and whether auto-renewal is turned on.
Swipe the table sideways to see more
| Item | Analogy | When it happens |
|---|---|---|
| Domain | The address on your shop sign | Connected once at the start, renewed every year |
| Hosting | The building your shop is in | Kept running the whole time the site is live |
| Deployment | Stocking the shelves with new products | Happens at launch and every time you make changes |
Why don't changes show up right after deployment?
Usually it's because an old version of the page is stored (cached) somewhere. A cache temporarily keeps files that were already downloaded so the same page can load faster, and right after a deployment, that can make the old version appear.
Caches exist in the browser on a customer's phone and in content delivery networks (CDNs), which keep copies of your website in many regions to deliver it faster. Messengers like KakaoTalk also store link preview images and titles separately, so even after you change your main image, the messenger preview may stay the same for a while.
When checking, opening the site in a private browser window or on another phone reduces the effect of the cache. The descriptions shown in search results only change after the search engine visits again, which can take a few days.
How do I roll back if something goes wrong after deployment?
Many hosting services keep previous deployment versions, so if something goes wrong, they roll back by pointing the address to the version just before (a rollback). For example, Vercel documents a feature for instantly reverting to a previous production deployment.
What gets rolled back, though, is the screens and the code. Data customers left in the meantime, like bookings, orders and inquiries, is stored separately and doesn't roll back with it. That's why you back up first before a big deployment that changes how data is structured.
So if you keep a deployment record of "what was changed and when," you can quickly find which deployment caused a problem and go back to the version just before it.
You'll rarely have to press a rollback button yourself, but if the agency tells you "we can switch back to the previous version right away if anything goes wrong," you can hand over deployments with much more peace of mind.
When is the best time to deploy?
The usual rule of thumb is to deploy when you have the fewest customers, on a day you can respond right away if something goes wrong. A deployment rarely takes a website down by itself, but if there's a mistake in what changed, customers may spot it first.
A restaurant should avoid the time just before lunch or dinner service, and a hair salon is better off pushing changes at a quiet weekday time rather than on a busy weekend morning. If a craft studio plans to announce a new class, it's safest to deploy a day before the announcement and finish checking too.
For content that has to change at a set time, like the start of an event or a sale, agree on the schedule and who will check it with the agency in advance.
Watching for about 30 minutes after a deployment to make sure inquiry and booking notifications come in as usual is also a good habit. If notifications suddenly stop, tell the agency right away so they can decide whether to roll back.
What should I ask a web agency about deployment?
Every agency deploys differently, so asking at the start keeps things from getting confusing each time you request a change.
When you're told a deployment is done, open the changed pages listed in the message yourself and reply that everything looks fine. That leaves a record you both can check of when each change was finished.
If your website has an admin panel you can edit yourself, also ask whether changes go live the moment you save or need a separate deployment. Depending on the setup, the time it takes for your edits to appear to customers will differ.
- How long it usually takes from a change request to deployment
- Whether you get a chance to check a preview before deployment
- How they let you know when deployment is done
- Whether they can roll back to a previous version if something goes wrong
- How often booking and order data is backed up
- Whether urgent fixes (like a pricing error) are pushed live outside business days
For example
- When a restaurant asks for a price list update, the new prices only show on customers' phones once the edit is made and deployed.
Just check these
- You've checked the updated page on your own phone after deployment
- Key buttons like booking · inquiry still work
- There's a way to roll back if something goes wrong
Does my business need it?
It happens at launch and every time something is changed.
At ISSYMO
With a maintenance subscription, when you send an edit request we make the change, deploy it, and send you a completion notice with a link to the updated page.
See maintenanceFAQ
Sources
Last updated