Getting a Website Online: Hosting, Deployment and Continuous Improvement
Learn how deployment works, how hosting options compare, and how to keep improving a website after it goes live.
Leaving Your Laptop
A website is not truly finished when it works on your computer.
That is only the "it works in my room" stage. Deployment is the process of putting the website somewhere other people can access it through a browser. It is the point where your files leave the cosy little nest of your laptop and meet the wider internet.
This is also where hidden problems often appear: broken image paths, missing files, incorrect folder structure, case-sensitive filenames, and pages that only worked because they were sitting on your own machine.
- Have you ever had a file, image, or link work locally but fail somewhere else?
- What would you want to check before sending a live website link to another person?
- Which feels clearer right now: building the site or publishing it?
This lesson sits before Black Swan Bistro Part 5 so the deployment system makes sense before you prepare a project for production.
Learning Objectives
By the end of this lesson, you'll be able to:
- Explain what deployment means
- Describe the difference between a local website and a live website
- Identify the basic parts of web hosting
- Understand traditional hosting, manual static hosting, and Git-based deployment
- Deploy a simple HTML, CSS and JavaScript website using an appropriate method
- Compare static and dynamic hosting needs at a beginner level
- Understand how Vite changes the deployment process
- Explain the basic role of domains, DNS records, and propagation
- Use a pre-deployment checklist before publishing
- Create a simple continuous improvement workflow
- Recognise the difference between student practice hosting and production-ready hosting
Why This Matters:
Deployment is where your project becomes part of the web. Understanding the system helps you choose the right hosting method, avoid folder mistakes, and keep improving the site after launch.
Before You Start:
You should be familiar with:
- Git Basics Review here
- Test and Validate Your Site Review here
Where This Lesson Fits
This is a general deployment tutorial. It is not tied to one project. You will use these ideas later when you deploy project work such as Black Swan Bistro, Rotto Rocks, portfolio projects, small business websites, accessibility practice projects, and SEO practice projects.
The aim is to understand the system before pressing buttons. Button pressing is easy. Understanding why the buttons matter is the useful bit.
What Deployment Means
Deployment means publishing a website so it can be viewed online. For a basic static website, the browser needs access to the site files: HTML, CSS, JavaScript, images, fonts, and other assets.
Your local project folder is like the kitchen. Deployment is putting the finished meal on the table. The browser cannot access your laptop directly, so the website needs to be placed on a server or hosting platform that is connected to the internet.
Key Terms
| Term | Meaning |
|---|---|
| Local site | The version of the website stored on your own computer. |
| Live site | The version of the website available online. |
| Web host | A service that stores and serves website files. |
| Domain name | The human-friendly address for a website. |
| Server | A computer that sends website files to visitors. |
| Deployment | The act of publishing or updating the live site. |
| Static site | A website made from files that do not need server-side processing. |
| Build | The process of preparing a development project for production. |
| Output folder | The folder generated by a build process, such as dist in many Vite projects. |
Local Files Versus Live Websites
When you are learning HTML, CSS and JavaScript, you may open index.html directly from your computer and see the page in your browser. That is useful for early testing. It is not the same as deploying the site.
Local viewing can hide problems such as:
- file paths that only work on your machine
- filenames that fail on case-sensitive servers
- missing files hidden by browser cache
- forms that do not behave as expected
- routing issues
- image paths that point to the wrong location
- mobile layout problems
- JavaScript errors that only appear after deployment
The site working on your laptop is encouraging. It is not yet evidence. Deployment is where the browser gets brutally honest.
Checkpoint: Is This Ready to Leave Your Laptop?
Before you deploy, can you answer these?
- Why is "it works on my laptop" not enough evidence that a site is ready?
- What file does a static host usually look for first at the root of the site?
- Why should filenames be simple, consistent, and lowercase before deployment?
Check Your Answers
- Local testing can hide problems with paths, missing files, case-sensitive filenames, mobile layout, cache, and deployment folder structure. A live site has to work from a server for someone else, not just from your own computer.
- Most static hosts look for index.html. If that file is missing or nested one folder too deep, the homepage may not load at the main address.
- Many servers treat uppercase and lowercase filenames as different. Simple lowercase names reduce path mistakes and make links, images, CSS, and JavaScript easier to debug.
How confident are you with this concept?
Still confused | Getting there | Got it | Could explain it to a friend
Quick Pre-deployment Check
- Does the homepage open correctly?
- Do all navigation links work?
- Are images stored inside the project folder?
- Are filenames simple, consistent and lowercase?
- Are CSS files linked correctly?
- Are JavaScript files linked correctly?
- Does the site work on a phone-sized screen?
- Are there no obvious console errors?
- Is the main page named
index.html? - Have you removed placeholder content?
The Three Main Hosting Paths
There are many hosting services, but beginner deployment usually falls into three broad paths.
Free hosting is useful for learning, not magic. Free plans may have limits, slower performance, platform branding, usage caps, less support, or features that change over time. That can be fine for student practice. A business, client, or long-term project may need more reliable hosting, backups, support, and clear ownership.
Student Hosting Options
The right hosting choice depends on what you are practising. A first deployment does not need the fanciest platform. It needs a clear path, a live URL, and a workflow you can repeat without losing track of your files.
| Pathway | GitHub required? | Best for | Main caution |
|---|---|---|---|
| Traditional free hosting | No | Learning file upload and public folders | Limits, slower performance, limited support |
| Manual static hosting | No | Quick static demos and prototypes | Manual updates can become confusing |
| GitHub Pages | Yes | Simple static sites and portfolios | Requires GitHub confidence |
| Netlify with GitHub | Yes | Ongoing static and Vite projects | Build settings matter |
| Vercel with GitHub | Yes | Vite projects and modern frontend workflows | Check plan terms for commercial use |
| Paid hosting | Varies | Business, client, and long-term sites | Costs, renewal pricing, support quality, and ownership details |
Traditional hosting practice
Services such as InfinityFree and AwardSpace can help students see a real hosting dashboard, file manager, and public website folder. They are useful for practising uploads to folders such as htdocs or public_html.
Use this path when the goal is understanding where files live on a host. Do not treat free traditional hosting as the default answer for client or business sites.
Manual static hosting practice
Netlify Drop, Vercel Drop, and Cloudflare Pages Direct Upload are useful when students need a quick live URL without GitHub. For plain HTML, CSS and JavaScript, upload the folder that contains index.html.
For Vite, run npm run build first, then use the generated dist output if the provider asks for prebuilt static files.
Git-based hosting practice
GitHub Pages is a good fit for simple static sites, portfolios, and documentation once students understand repositories. Netlify and Vercel can connect to GitHub and redeploy when changes are pushed.
For plain HTML/CSS/JS, the publish directory is usually the project root or the folder containing index.html. For Vite, the common settings are npm run build and dist.
Paid hosting later
Paid hosting is not required for this tutorial. It becomes more relevant when a site needs a custom domain, email accounts, stronger reliability, better support, or business credibility.
Read plan terms before using any host for commercial work. Hosting services change limits, pricing, acceptable use rules, and signup flows over time.
Static vs Dynamic Deployment
Most beginner HTML, CSS and JavaScript projects are static sites. That does not mean they are boring. It means the host can serve finished files directly to the browser without running server-side code for every visitor.
A dynamic site needs server-side processing, a database, logged-in user areas, real checkout flows, or other backend behaviour. Those projects need a hosting choice that supports more than static files.
| Site type | Usually contains | Beginner hosting fit |
|---|---|---|
| Static | HTML, CSS, JavaScript, images, fonts, built Vite output | Traditional hosting, manual static hosting, GitHub Pages, Netlify, Vercel, Cloudflare Pages |
| Dynamic | Server code, databases, authentication, private dashboards, checkout, CMS editing | Requires platform support for backend features, databases, serverless functions, or a CMS |
Good news: Black Swan Bistro, portfolio demos, landing pages, and many small informational sites can start as static sites. Reach for dynamic hosting when the project actually needs dynamic behaviour, not because the word sounds more professional.
Plain HTML, CSS and JavaScript Deployment
For a plain static website, your project might look like this:
my-website/
├── index.html
├── about.html
├── styles.css
├── script.js
└── images/
└── hero.jpgTo deploy this kind of site manually, you usually upload the files as they are. The most important rule is this:
index.html must be in the correct public folder.
If you upload the whole my-website folder into the hosting folder, your homepage may end up one level too deep.
Usually wrong for the main address
htdocs/
└── my-website/
└── index.htmlUsually better
htdocs/
├── index.html
├── about.html
├── styles.css
├── script.js
└── images/
└── hero.jpg The server looks for index.html first. Do not make it go on a treasure hunt.
Vite Deployment
A Vite project is different from a plain HTML folder. During development, you usually run:
npm run devThat starts a local development server. Before deployment, you usually run:
npm run buildThis creates a production-ready version of the site. In many Vite projects, the output folder is:
dist/ For manual deployment, you usually upload the contents of the dist folder or the dist folder itself, depending on the hosting service instructions. For Git-based deployment with Netlify or Vercel, you usually set:
| Setting | Value |
|---|---|
| Build command | npm run build |
| Output / publish directory | dist |
Plain sites first, Vite as an extra path. Do not upload the whole development project folder to a manual host and expect it to behave like the finished site. Your source files are the workshop. Your dist folder is the packed and polished version ready for visitors.
index.html. Vite adds a build step: the deployable version is the generated output folder. Domains, DNS, and Going Live
A deployment gives your site a live address, often on a hosting provider’s subdomain. A custom domain is the human-friendly name you can point at that hosted site. DNS is the system that tells browsers where that domain should go.
You do not need a custom domain for your first student deployment. Learn the hosting workflow first. Add domain setup when the site is ready to be shared more seriously.
Common DNS pieces
- Domain registrar: where the domain is registered and renewed.
- DNS records: instructions that point names to services.
- A record: points a domain or subdomain to an IP address.
- CNAME record: points one name to another hostname.
- Nameservers: tell the internet which DNS provider manages the domain.
Going-live checks
- Follow the exact DNS instructions from your hosting provider.
- Check whether you are setting an apex domain, such as
example.com, or a subdomain, such aswww.example.com. - Wait for DNS propagation before assuming something is broken.
- Test both
http://andhttps://after SSL is enabled. - Record where the domain, DNS, hosting, and repository are managed.
Do not guess DNS records. Hosts change their domain setup instructions, and different account types can use different records. Use the current instructions from the host and registrar, then test the live domain after the change has had time to settle.
Guided Practice: Deploy a Tiny Test Site
Before deploying a larger project, create and deploy a tiny test website. This keeps the first deployment low-pressure. If something breaks, there are only three files to inspect.
Deploy a Tiny Test Site
Step 1: Create a tiny deployment test folder
Create a folder called deployment-test. Inside it, add index.html, styles.css, and script.js. Keep this first deployment deliberately small so any problem is easy to find.
Need a hint?
Step 2: Add the test HTML, CSS, and JavaScript
Use the code examples in the next section. Check that the page opens locally, the stylesheet loads, and the button updates the message text.
Need a hint?
Step 3: Choose one deployment method
Deploy the tiny site using traditional hosting, Netlify Drop, Vercel Drop, GitHub Pages, Netlify with GitHub, or Vercel with GitHub. Follow the hosting service instructions for the method you choose.
Need a hint?
Step 4: Test the live URL
Open the published URL in a normal browser window and a private or incognito window. Click the JavaScript button, check the layout on a narrow screen, and record any issue you find.
Need a hint?
You're on track if you can:
- The live URL opens from a browser
- The homepage loads from index.html
- The stylesheet loads on the live site
- The JavaScript button works on the live site
- You recorded the deployment method, live URL, and at least one test result
Create This Folder Structure
deployment-test/
├── index.html
├── styles.css
└── script.jsCreate index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Deployment Test</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<main>
<h1>My first deployed test site</h1>
<p>If you can read this online, deployment worked.</p>
<button id="messageButton">Test JavaScript</button>
<p id="message"></p>
</main>
<script src="script.js"></script>
</body>
</html>Create styles.css
body {
font-family: system-ui, sans-serif;
margin: 0;
padding: 2rem;
background: #f7f3ed;
color: #222;
}
main {
max-width: 42rem;
margin: 0 auto;
}
button {
padding: 0.75rem 1rem;
border: 0;
border-radius: 0.5rem;
cursor: pointer;
}Create script.js
const button = document.querySelector('#messageButton');
const message = document.querySelector('#message');
button.addEventListener('click', () => {
message.textContent = 'JavaScript is working on the live site.';
});Deploy this test site using one method:
- traditional hosting
- Netlify Drop
- Vercel Drop
- GitHub Pages
- Netlify with GitHub
- Vercel with GitHub
Then complete the deployment checklist.
Independent Practice: Choose Your Deployment Path
Now try this on your own without hints!
Your Task:
Choose one deployment option and record enough detail that you could repeat the process later. If you want a stronger comparison, deploy the same tiny site twice: once manually and once with GitHub integration.
Requirements:
- Record the hosting service and deployment method
- Record the folder uploaded or repository connected
- Record the live URL
- Test the live URL in a normal and private browser window
- Record one issue you found or one change you made after the first deployment
Stretch Goals (Optional):
- Compare manual deployment with Git-based deployment
- Explain which method feels safer for future changes
- Decide which method you would use for a student project and which you would use for a real client site
Success Criteria:
| Criteria | You've succeeded if... |
|---|---|
| Deployment evidence | The learner records the hosting service, live URL, folder or repository used, and any build settings. |
| Testing | The learner tests the live URL, checks links/assets, and records at least one issue or confirmation. |
| Method fit | The learner can explain why manual hosting, drag-and-drop hosting, or Git-based deployment suited the task. |
| Improvement workflow | The learner can make one small update, redeploy it, test it live, and record the change. |
Continuous Improvement Workflow
Deployment is not the end of the work. It is the beginning of maintaining the site. A simple improvement workflow prevents you from randomly changing files and hoping for the best.
Manual hosting workflow
Notice issue → Write it down → Fix local file → Test locally → Upload changed file → Test live site → Record the change| Step | Why it matters |
|---|---|
| Notice issue | You identify what needs to change. |
| Write it down | You avoid relying on memory. Memory is not a project management system. |
| Fix local file | You update the source version first. |
| Test locally | You catch obvious mistakes before uploading. |
| Upload changed file | You update the live site. |
| Test live site | You confirm the real website works. |
| Record the change | You create a history of what happened. |
Git-based workflow
Notice issue → Create issue or task → Fix locally → Test locally → Commit → Push → Deployment runs → Test live siteGitHub-connected deployment creates a cleaner trail of changes. You can see what changed, when it changed, and often why it changed. That is helpful when something breaks and the website starts behaving like it has joined a witness protection program.
Student Improvement Log
| Date | Issue or improvement | Change made | Tested locally? | Tested live? | Notes |
|---|---|---|---|---|---|
| YYYY-MM-DD | Navigation link broken | Fixed file path | Yes | Yes | Link now works |
| YYYY-MM-DD | Image too large | Compressed image | Yes | Yes | Page loads faster |
Common Deployment Problems
My homepage does not load
Likely causes: index.html is missing, the wrong folder was uploaded, the file is inside the wrong folder, or the host has not finished setting up.
Fix: check the public folder, move index.html to the correct location, refresh the live URL, and wait a few minutes if the host is still provisioning the site.
CSS is missing
Likely causes: the CSS path is wrong, the file was not uploaded, the filename uses different capitalisation, or the folder structure changed.
Fix: check the <link> path, check the uploaded folder, and match file and folder names exactly.
Images are broken
Likely causes: image files were not uploaded, local file paths were used, folder names do not match, capitalisation differs, or filenames contain spaces.
Fix: use relative paths, use simple lowercase filenames, keep images in the project folder, and re-upload missing images.
The site works locally but not online
Likely causes: local file paths, incorrect folder upload, case-sensitive filename issues, Vite source uploaded instead of build output, or incorrect build settings.
Fix: check paths, check the public folder, run the build command if using Vite, upload dist if deploying manually, and check build logs if using Git deployment.
Updates do not appear
Likely causes: browser cache, the wrong site or folder was updated, deployment is still processing, or the Git push did not happen.
Fix: hard refresh, check the deployment dashboard, check the live URL, confirm the correct folder or repository, and test in a private browser window.
Deployment Checklist
Use this checklist before and after deploying a website. It is designed for beginner HTML, CSS and JavaScript projects, with extra notes for Vite projects.
Copy or download the checklist
The checklist below is plain Markdown so students can paste it into notes, a README, a project issue, or a shared document.
Preview the full deployment checklist
# Deployment Checklist
Use this checklist before and after deploying a website.
It is designed for beginner HTML, CSS and JavaScript projects, with extra notes for Vite projects.
## Student details
| Item | Details |
|---|---|
| Student name | |
| Project name | |
| Deployment method | |
| Hosting service | |
| Live URL | |
| Date deployed | |
## 1. Files and folders
- [ ] My homepage is named `index.html`.
- [ ] My CSS file is linked correctly.
- [ ] My JavaScript file is linked correctly.
- [ ] My images are inside the project folder.
- [ ] My folder names are simple and consistent.
- [ ] My file names do not contain accidental spaces.
- [ ] My file names use consistent lowercase naming.
- [ ] I have not linked to files on my own computer using local file paths.
- [ ] I have removed unused test files.
- [ ] I know which folder needs to be uploaded or deployed.
## 2. Content
- [ ] The page title is meaningful.
- [ ] The main heading is clear.
- [ ] Placeholder text has been removed.
- [ ] Spelling and obvious grammar errors have been checked.
- [ ] Images have useful alt text where needed.
- [ ] Decorative images have empty alt text if appropriate.
- [ ] Contact or business details are correct.
- [ ] Navigation labels make sense.
- [ ] Buttons and links use clear text.
- [ ] The website makes sense to someone who did not build it.
## 3. Layout and accessibility
- [ ] The site works on desktop.
- [ ] The site works on mobile.
- [ ] Text is readable.
- [ ] Buttons and links are easy to tap.
- [ ] Colour contrast is acceptable.
- [ ] Keyboard focus is visible.
- [ ] The page has a logical heading order.
- [ ] Content does not overflow sideways on mobile.
- [ ] Images resize appropriately.
- [ ] Animations or movement are not distracting.
## 4. Technical checks
- [ ] All navigation links work.
- [ ] All images load.
- [ ] CSS loads correctly.
- [ ] JavaScript loads correctly.
- [ ] The browser console does not show obvious errors.
- [ ] The site works in a private or incognito browser window.
- [ ] The site has been refreshed after deployment.
- [ ] I tested the live URL, not just the local file.
- [ ] I tested at least one link from each page.
- [ ] I tested any button or interaction I added.
## 5. Deployment method checks
### If using traditional hosting
- [ ] I know the name of my public website folder.
- [ ] I uploaded the correct files to the correct folder.
- [ ] `index.html` is in the public website folder.
- [ ] CSS, JavaScript and image folders were uploaded.
- [ ] I did not accidentally upload the project folder one level too deep.
- [ ] I checked the live site after uploading.
### If using manual static hosting
- [ ] I chose the correct folder to upload.
- [ ] For plain HTML/CSS/JS, `index.html` is at the root of the uploaded folder.
- [ ] For Vite, I ran the build command first.
- [ ] For Vite, I uploaded the generated `dist` folder or the required output folder.
- [ ] I recorded which folder I uploaded.
- [ ] I tested the generated live URL.
### If using GitHub Pages
- [ ] My project files are in a GitHub repository.
- [ ] My homepage is named `index.html`.
- [ ] I enabled GitHub Pages in repository settings.
- [ ] I selected the correct branch and folder.
- [ ] I waited for the site to publish.
- [ ] I opened the published GitHub Pages URL.
- [ ] I tested the live site.
### If using Netlify with GitHub
- [ ] My project is pushed to GitHub.
- [ ] Netlify is connected to the correct repository.
- [ ] I checked the build command.
- [ ] I checked the publish directory.
- [ ] For Vite, the build command is usually `npm run build`.
- [ ] For Vite, the publish directory is usually `dist`.
- [ ] I checked the deployment log if the build failed.
- [ ] I tested the live Netlify URL.
### If using Vercel with GitHub
- [ ] My project is pushed to GitHub.
- [ ] Vercel is connected to the correct repository.
- [ ] I checked the detected framework settings.
- [ ] For Vite, the build command is usually `npm run build`.
- [ ] For Vite, the output directory is usually `dist`.
- [ ] I checked the deployment log if the build failed.
- [ ] I tested the live Vercel URL.
## 6. After deployment
- [ ] I opened the live URL in a normal browser window.
- [ ] I opened the live URL in a private/incognito window.
- [ ] I checked the homepage.
- [ ] I checked all main pages.
- [ ] I checked navigation links.
- [ ] I checked images.
- [ ] I checked mobile layout.
- [ ] I checked browser console errors.
- [ ] I wrote down any issues.
- [ ] I fixed the most important problems.
- [ ] I tested the site again after fixing issues.
## 7. Continuous improvement check
- [ ] I created an improvement log.
- [ ] I recorded the first deployment date.
- [ ] I recorded the live URL.
- [ ] I wrote down any known issues.
- [ ] I prioritised the most important issue.
- [ ] I know how to update the site again.
- [ ] I know whether updates are manual or automatic.
- [ ] I kept a backup or version history.
## 8. Improvement log template
| Date | Issue or improvement | Change made | Tested locally? | Tested live? | Notes |
|---|---|---|---|---|---|
| | | | | | |
| | | | | | |
| | | | | | |
## 9. Deployment notes
Do not write passwords here. Record safe details only.
| Item | Notes |
|---|---|
| Hosting service | |
| Project/site name | |
| Live URL | |
| Repository URL | |
| Build command | |
| Output/publish folder | |
| Public hosting folder | |
| Date created | |
## 10. Final confidence check
1. Can someone else open the website from their own device?
2. Does the homepage explain what the site is?
3. Can visitors move around the site?
4. Are the most obvious errors fixed?
5. Do I know how to make the next update?
If you can answer yes to those questions, the site is ready to share for review.
If not, that is not failure. That is testing doing its job.
Reflection Questions
Answer these after your first deployment:
- What surprised you about deployment?
- What part of the process felt most confusing?
- What is the difference between uploading files and managing a project?
- Why might a business website need more reliable hosting than a class exercise?
- How does Git-based deployment support continuous improvement?
- What would you check before sending a live URL to someone else?
Recap
Deployment means putting a website online. Static websites can be hosted using traditional hosting, manual static hosting, or Git-based workflows. Free hosting is useful for learning, but it has limits. Paid hosting may be appropriate for business, client and long-term projects.
GitHub integration helps with repeatable deployment and continuous improvement. Testing the live site is essential. A checklist prevents avoidable mistakes. In the next Black Swan Bistro project step, you will apply this workflow to prepare the bistro website for deployment, test it as a real visitor, and create a simple improvement log.
Ready to Publish With Evidence
Key Takeaways:
- Deployment means putting a website online where other people can reach it.
- Plain HTML, CSS, and JavaScript sites can usually be deployed as static files.
- Traditional hosting, manual static hosting, and Git-based deployment each teach different parts of the system.
- Vite projects usually need a build step before deployment; the finished output is commonly the dist folder.
- Free hosting is useful for learning, but production and business sites may need stronger reliability, support, and ownership.
- Testing the live site is essential because deployment exposes problems local testing can hide.
- A checklist and improvement log turn launch into a repeatable workflow.
Learning Objectives Review:
Look back at what you set out to learn. Can you now:
- Explain what deployment means Check!
- Describe the difference between a local website and a live website Got it!
- Identify the basic parts of web hosting Can explain it!
- Understand traditional hosting, manual static hosting, and Git-based deployment Could teach this!
- Deploy a simple HTML, CSS and JavaScript website using an appropriate method Check!
- Compare static and dynamic hosting needs at a beginner level Got it!
- Understand how Vite changes the deployment process Can explain it!
- Explain the basic role of domains, DNS records, and propagation Could teach this!
- Use a pre-deployment checklist before publishing Check!
- Create a simple continuous improvement workflow Got it!
- Recognise the difference between student practice hosting and production-ready hosting Can explain it!
If you can explain the hosting method, identify the correct folder, test the live URL, and record the next improvement, you are ready to move from local project to live website with a much calmer pulse.
Think & Reflect:
First Launch
- Which part of deployment felt most concrete once you saw the live URL?
- Which part still feels abstract enough that you would want to practise it again?
Future Workflow
- What would you check before sending a live URL to someone else?
- Which deployment method would you choose for a class exercise, and which would you choose for a business site?
Looking Ahead:
Next, move into Black Swan Bistro Part 5 with the deployment system already mapped in your head. The project-specific step can focus on preparing the bistro site instead of making hosting feel like a fog machine.
Additional Resources
Internal next steps
Official hosting references
Recommended Next Steps
Continue Learning
Ready to move forward? Continue with the next tutorial in this series:
Black Swan Bistro — Part 5 (Prepare for Deployment)Related Topics
Explore these related tutorials to expand your knowledge: