Right now your app runs on your machine, at an address only you can reach. Deploying means putting it somewhere with a permanent address so anyone can open it.
This used to be genuinely difficult. It now takes about ten minutes, and most of this lesson is about the parts that come after.
What hosting actually is
Someone else's computer, always on, connected to the internet, with your app on it. That's it.
For a static site, meaning pages that don't change per visitor, hosting is free and effectively unlimited. Cloudflare Pages, Netlify, Vercel and GitHub Pages all do this at no cost.
For an app with a backend, you need something that can run code and talk to a database. Vercel, Render, Railway, Fly. Free tiers exist and are plenty for launching.
The usual arrangement: connect your git repository, and every time you push changes it rebuilds and updates the live site automatically. Set up once, forgotten thereafter.
Get a domain
Your host will give you something like my-app-3f9a.vercel.app. It works, and it looks temporary, because it is.
A domain costs around $10 a year. Cloudflare and Namecheap are both fine. Buy it early, because it also affects your email, which we'll get to in a moment.
DNS is the system that connects a domain to a server, and it has a reputation for being confusing. In practice you'll add one or two records that your host tells you to add, and it'll work. Changes can take a few minutes to spread, occasionally longer, which is usually what's happening when something "doesn't work" right after you set it up.
Why your email disappears
This one surprises everybody, and it's worth understanding before you send anything important.
You set up an address, send a welcome email to a new signup, and it silently lands in spam. Not bounced, not rejected. Just quietly filed where nobody looks.
The reason is that email was designed without much thought about people lying about who they are, so anyone can claim to send from any address. Mail providers compensate by being suspicious by default. To be trusted, you have to prove the mail genuinely comes from you, using three DNS records.
SPF lists which servers are allowed to send for your domain. DKIM adds a cryptographic signature proving the message wasn't tampered with. DMARC tells receiving servers what to do when the first two fail.
You don't need to understand the mechanics. You need to know that without all three, your email quietly vanishes, and that your email provider gives you the exact records to paste in.
Use a proper sending service, Resend, Postmark, Brevo, rather than sending mail from your app server directly. They handle deliverability as their whole business, and free tiers cover early volumes easily.
Send yourself a test to a Gmail address and check it doesn't land in spam. That one check catches most of it.
The site you need before the app store
If you're shipping a mobile app, this catches people out at the worst moment.
App stores require a privacy policy URL, and generally a support URL, before they'll accept your submission. Both need to be live and reachable.
So a website isn't optional even for a phone app. It doesn't need to be elaborate, a single page with what the app does, a privacy policy, and a way to contact you covers it. But it does need to exist before you submit, and finding that out on submission day is a bad time to discover it.
A few things worth setting up once
Some small pieces that take minutes and prevent later annoyance.
HTTPS, the padlock, should be automatic with any modern host. If it isn't, that's a problem, not a preference.
A proper 404 page, so a wrong link shows something helpful instead of a blank error.
And a support email on your own domain. [email protected] rather than a personal gmail. It's free with most domain providers via forwarding, and it changes how seriously people take you.
A quick story. Getting email to actually arrive took me considerably longer than getting the site online. The site was minutes. The email was an afternoon of records, waiting for changes to propagate, sending test messages to myself, and finding them in spam.
What made it slow was that failure is silent. A broken page you notice immediately. Email that lands in spam looks exactly like email that worked, from your side. Everything reports success. The message simply isn't where the person would look.
If your app sends anything that matters, and a signup confirmation matters, it's worth testing to a few real inboxes before you rely on it.
If you want help getting online
Point four saves a day. It's the sort of thing you find out at the exact moment you were hoping to be finished.
Next: Submitting to the App Store →
Go deeper: Chapter 33, Deployment and CI/CD, Chapter 34, Web Infrastructure and Chapter 35, Domains, Email and Deliverability