Deploying Your First Project to the Internet
Take a project from localhost to a live URL that anyone can visit. Cover Vercel, Railway, custom domains, HTTPS, and environment variables.
What deployment means and why it matters
When you run a project on your computer, only you can see it. The app runs on localhost — your local machine. Deployment means putting your project on a server that is connected to the internet so anyone with the URL can access it. This is the difference between a side project and a real product. Deployment used to be complex: you rented a server, installed an operating system, configured web server software, set up firewalls, managed SSL certificates, and hoped nothing crashed at 3am. Modern platforms like Vercel and Railway have reduced this to a single command. Your code goes up, a URL comes back, and the platform handles servers, scaling, HTTPS, and uptime. There are two main categories of deployment. Static hosting is for websites that are just HTML, CSS, and JavaScript files — no server-side logic. Vercel, Netlify, and GitHub Pages handle static hosting excellently. Server hosting is for applications that run backend code — APIs, databases, server-side rendering. Railway, Render, and Fly.io handle server hosting. Next.js applications typically deploy to Vercel because Vercel built Next.js and optimises for it. Create a project to deploy: ask Claude Code: Create a simple Next.js application with a homepage that shows a heading, a paragraph describing the app, and a footer with the current year. Use Tailwind CSS for styling. Keep it minimal — we are focusing on deployment, not design. This gives you something real to deploy in the next section.
Deploying to Vercel
Vercel is the easiest deployment platform for Next.js and frontend projects. Ask Claude Code: Walk me through deploying this Next.js project to Vercel. I want to use the Vercel CLI, not the web dashboard. Here are the steps Claude Code will guide you through. First, install the Vercel CLI: npm install -g vercel. Second, log in: vercel login. This opens your browser to authenticate. Third, from your project directory, run: vercel. That is it. Vercel will ask a few questions: which account to deploy to (select yours), whether to link to an existing project (say no for a new project), what the project name is, and which directory contains your code. Accept the defaults. After about 60 seconds, you will get a URL like https://your-project-abc123.vercel.app. Open it in your browser — your site is live on the internet. Anyone with that URL can see it. Run vercel --prod to deploy to your production URL (without the random suffix). Ask Claude Code: Show me how to set up automatic deployments so every time I push to GitHub, Vercel deploys automatically. Claude Code will explain: connect your GitHub repository in the Vercel dashboard, and every push to main triggers a production deployment. Every pull request gets a preview deployment with its own URL — perfect for reviewing changes before they go live. Common issues: if the build fails, check the Vercel deployment logs with vercel logs. The most common failures are missing dependencies (add them to package.json, not just installed globally), build errors (test locally with npm run build first), and environment variables not set on Vercel.
Deploying backend apps to Railway
If your project has a backend — an API, a database, background jobs — Railway is an excellent choice. Ask Claude Code: Create a simple Express.js API with three endpoints: GET / returns a welcome message, GET /api/time returns the current server time, and GET /api/health returns a status check. Add a start script to package.json. Test it locally: node server.js. Visit http://localhost:3000 in your browser to confirm it works. Now deploy: install the Railway CLI: npm install -g @railway/cli. Log in: railway login. Initialise: railway init and choose to create a new project. Deploy: railway up. Railway detects your Node.js project, installs dependencies, and starts it. After about 90 seconds, you get a URL. Ask Claude Code: How do I add a PostgreSQL database to this Railway project? Claude Code will explain: run railway add and select PostgreSQL. Railway provisions a database and injects the connection URL as the DATABASE_URL environment variable. Your code can read it with process.env.DATABASE_URL. No manual configuration needed. Ask Claude Code: Update the Express API to connect to the PostgreSQL database. Add an endpoint POST /api/messages that stores a message, and GET /api/messages that retrieves all messages. Use the pg package. Run railway up again to deploy the updated code. Test by sending a POST request to your live URL: curl -X POST -H "Content-Type: application/json" -d "{\"text\": \"Hello from the internet\"}" https://your-app.railway.app/api/messages. Then visit the GET endpoint in your browser to see your message. You have deployed a full backend application with a database in under 10 minutes.
Custom domains and DNS
Your deployed app has a URL like your-app.vercel.app or your-app.railway.app. A custom domain like yourname.com makes it look professional. Ask Claude Code: Explain how DNS works in simple terms and walk me through connecting a custom domain to my Vercel deployment. DNS (Domain Name System) translates human-readable domain names into IP addresses. When someone visits yourname.com, DNS tells their browser which server to connect to. You buy a domain from a registrar like Namecheap, Google Domains, or Cloudflare. Prices range from 8 to 15 dollars per year for common extensions. In the Vercel dashboard, go to your project settings and click Domains. Add your domain name. Vercel gives you DNS records to add at your registrar. Typically you need two records: an A record pointing to Vercel's IP address (76.76.21.21) and a CNAME record for the www subdomain pointing to cname.vercel-dns.com. Log into your domain registrar, find DNS settings, and add these records. DNS propagation takes anywhere from 5 minutes to 48 hours, but usually completes within 30 minutes. Ask Claude Code: How do I verify that my DNS records are correct? You can use dig yourname.com in your terminal or visit a DNS checker website. Once the records propagate, visiting yourname.com loads your Vercel deployment. Vercel automatically provisions an SSL certificate so your site works with HTTPS — the padlock icon in the browser. For Railway, the process is similar: add your domain in the Railway dashboard and configure DNS records at your registrar. Ask Claude Code: Should I use Cloudflare as my DNS provider? What are the benefits? Cloudflare offers free DNS hosting, DDoS protection, and CDN caching. Many developers use Cloudflare even when hosting elsewhere.
Environment variables and secrets
Environment variables store configuration that changes between environments — API keys, database URLs, feature flags. You never hardcode these in your source code. Ask Claude Code: Show me how to manage environment variables for local development and production deployment. For local development, create a .env.local file in your project root: OPENWEATHER_API_KEY=abc123 and DATABASE_URL=postgres://localhost:5432/mydb. Next.js automatically loads this file. Access values with process.env.OPENWEATHER_API_KEY. Never commit .env files to Git. Ask Claude Code: Add .env.local and .env to the .gitignore file. Create a .env.example file with the variable names but no values so other developers know what to configure. For Vercel, add environment variables in the dashboard under Project Settings then Environment Variables. Or use the CLI: vercel env add OPENWEATHER_API_KEY. Vercel lets you set different values for production, preview, and development environments. For Railway, environment variables are set in the dashboard under the Variables tab or via CLI: railway variables set OPENWEATHER_API_KEY=abc123. Ask Claude Code: Create a config.js module that reads all required environment variables at startup and throws a clear error if any are missing. List every variable the app needs with a description. This pattern catches missing configuration immediately instead of failing when the variable is first used — possibly minutes later in a rarely-hit code path. Common mistake: setting an environment variable on Vercel but forgetting to redeploy. Environment variables are injected at build time for Next.js, so you must trigger a new deployment after changing them. Run vercel --prod to force a redeploy.
Build errors and deployment debugging
Your project works locally but fails to deploy. This is the most common deployment frustration. Ask Claude Code: What are the most common reasons a project works locally but fails on Vercel or Railway? Create a troubleshooting checklist. The top causes are: missing dependencies — packages installed globally on your machine but not in package.json. Fix: run npm install in a fresh directory and verify the project builds. Case sensitivity — your Mac file system is case-insensitive but Linux servers are case-sensitive. Import from Components/Header.js works locally but fails if the file is components/header.js. Fix: match file name casing exactly. Environment variables — not set on the hosting platform. Fix: add all required variables in the platform dashboard. Node.js version — your local version differs from the platform default. Fix: add an engines field to package.json specifying your Node.js version. Build commands — the platform runs npm run build but your build script has an error. Fix: run npm run build locally first and fix all errors and warnings. Ask Claude Code: Run npm run build locally and tell me if there are any errors or warnings that would cause a deployment failure. Claude Code will run the build and report issues. Common Next.js build errors include pages using browser APIs during server-side rendering (wrap in useEffect or check typeof window), missing image dimensions (add width and height to Image components), and TypeScript errors that were warnings locally but are errors in strict mode. For deployment logs, check vercel logs or the Railway dashboard under Deployments. The logs show exactly what happened during the build and where it failed. Ask Claude Code: Analyse these deployment logs and explain what failed and how to fix it — then paste the logs.
Continuous deployment and preview URLs
The best deployment workflow is automatic: push code to GitHub and it deploys itself. Ask Claude Code: Set up a GitHub repository for this project and connect it to Vercel for automatic deployments. Walk me through each step. Claude Code will guide you through: git init, create a .gitignore (node_modules, .env.local, .next), git add and commit, create a GitHub repo with gh repo create, push your code, then connect the repo in the Vercel dashboard. Once connected, every push to the main branch triggers a production deployment. But the real power is preview deployments. Create a branch: git checkout -b add-about-page. Make changes. Push: git push -u origin add-about-page. Open a pull request. Vercel automatically builds a preview deployment with its own URL and posts it as a comment on the PR. You and your team can review the live changes before merging. When you merge the PR, Vercel deploys to production automatically. Ask Claude Code: Create a simple GitHub Actions workflow that runs npm run build and npm test before allowing a merge. This adds a safety check — code that does not build or pass tests cannot be merged and deployed. The workflow file goes in .github/workflows/ci.yml. Common setup: trigger on pull requests to main, run npm ci to install dependencies, run npm run build to verify the build, and run npm test if you have tests. If any step fails, the PR shows a red X and cannot be merged. This is continuous integration (CI) paired with continuous deployment (CD). Together, they mean you can ship changes confidently — tests catch bugs, preview URLs catch visual issues, and only verified code reaches production.
Post-deployment checklist
Your site is live. Now make sure it stays healthy. Ask Claude Code: Create a post-deployment checklist as a JSON file that I can use for every deployment. Include checks for functionality, performance, SEO, and security. The essential checks are: visit the live URL and test core functionality — pages load, links work, forms submit. Check the browser console for JavaScript errors. Test on mobile by resizing your browser or using device emulation in developer tools. Verify HTTPS — the padlock icon should appear and http:// should redirect to https://. Check that environment variables are working by testing features that depend on them. Run a Lighthouse audit in Chrome DevTools for performance, accessibility, best practices, and SEO scores. Ask Claude Code: Set up a simple uptime monitor that checks my site every 5 minutes and alerts me if it goes down. Options include UptimeRobot (free tier monitors up to 50 URLs) or a simple cron job. For ongoing monitoring, ask Claude Code: Add basic analytics to my site so I can see how many people visit and which pages are popular. Add a simple Plausible or PostHog snippet to the layout. Both offer free tiers and are privacy-friendly. Finally, set up error monitoring. Ask Claude Code: Add Sentry to the Next.js project for error tracking. When an error happens on the live site, Sentry captures it with full context — the stack trace, the browser, the URL, the user's actions leading up to the error. You get an email notification and can fix the bug before users report it. Your project is now deployed, monitored, and ready for real users. The distance from localhost to live URL is smaller than it has ever been — and with Claude Code handling the configuration, you can focus on building features instead of fighting infrastructure.
Shipping Your First Project
This guide is hands-on and practical. The full curriculum covers the conceptual foundations in depth with structured lessons and quizzes.
Go to lesson