Deploying Full-Stack

What you are shipping

Your Level 5 product is no longer just a folder of HTML. A visitor loads a Svelte page, the page sends requests to a server endpoint, and that endpoint reads or writes a hosted PostgreSQL table. A working deployment must connect all three. A page that looks right but cannot save is not a finished full-stack product.

Draw this journey in your notes:

Browser → HTTPS host → SvelteKit POST endpoint → database
Browser ← success/error response ← endpoint ← database result

The browser must never receive a database password or a privileged service key. The host runs server-only code; the database service keeps the records. The browser sees only the response you deliberately return.

First make the local product trustworthy

From the folder containing your SvelteKit package.json, stop the development server with Ctrl+C and run the project's checks:

npm run check
npm run build
npm run preview

The TypeScript template normally provides check; inspect package.json if the script is absent rather than inventing an unrelated command. The preview command serves a production build locally. Open the exact address printed by the terminal; the port need not match your development server.

A successful build proves the files can be compiled, not that your database or permissions work. In the previewed app, add a harmless record, reload, and confirm it remains. Send invalid input and confirm it is rejected without adding a row. Check both the browser Console and the server terminal. Stop if a failure is unexplained.

Pick a host that runs your server

A static host can serve built assets but cannot run arbitrary SvelteKit server endpoints. Choose a supported full-stack deployment integration: for example Vercel's SvelteKit support or Cloudflare Pages/Workers with the matching SvelteKit adapter. An adapter turns the framework's output into the format a particular host expects.

Follow the current SvelteKit adapter guide for that host. If using Cloudflare, @sveltejs/adapter-cloudflare and the host's runtime configuration matter; if using Vercel, use its documented SvelteKit integration or @sveltejs/adapter-vercel. Do not choose a static-export adapter for a product that requires a live +server.ts endpoint. A library that relies on Node-only filesystem APIs may not run on an edge host even when it works locally.

Your database remains at its managed service. Deploying the application does not copy the database into the web host or create missing tables and policies for you.

Keep configuration separate from source

In this course's practice database setup, PUBLIC_SUPABASE_URL and PUBLIC_SUPABASE_PUBLISHABLE_KEY are intentionally public project configuration. The public key is not permission to bypass policies. Database passwords, service-role keys and secret API credentials are different: they are server-only secrets and must never use the PUBLIC_ prefix or be imported into a page component.

Before your first push:

1. Confirm .env and environment files holding private values are ignored; a harmless .env.example can list variable names without real values.
2. Run git status and inspect the staged diff. If an environment file was already tracked, adding it to .gitignore will not remove it from history.
3. Use git check-ignore .env to check the ignore rule. Expected output includes .env. Do not print the file's contents for a submission.
4. If a private key was committed or shared, revoke/rotate it through the issuing service. Deleting it in a later commit does not undo exposure.

Enter the required values in your chosen host's environment-variable settings. Set them for the environment you intend to test: preview and production can have separate settings. Never paste a secret into a build command, source file, public variable, screenshot or log. Some variables are read at build time: after changing them, redeploy as the host's documentation requires.

Rehearse one deployment from GitHub

1. Commit the working product and push it to the repository you own. Confirm GitHub shows that exact commit.
2. In the host, import that repository and select the directory containing the SvelteKit package.json. This matters if the app is inside a workspace subfolder.
3. Confirm the detected framework, documented adapter and build command. Use the host's SvelteKit defaults unless the project requires something different.
4. Enter configuration, then start the deploy. Watch the build log until it finishes; a started job is not a published product.
5. Open the host-provided HTTPS address before adding a custom domain. Fix application problems on that address first.
6. Change a visible harmless label, commit and push again. Confirm the deployed commit updates and the label changes. This proves your update pipeline, not just the first upload.

A custom domain is optional for this rehearsal. Do not buy a domain or paid plan to complete the learning checks; choose an available free tier within its current limits.

Diagnose the stage that failed

Do not log credentials to check configuration. Log whether a required value is present, or a safe error category. A generic browser message such as “Could not save” helps the user recover; detailed server diagnostics help you locate the cause.

Verify like a new visitor

Test the deployed HTTPS address in a fresh private window:

• Load the page and a nested page directly, then reload; do not rely on already-cached navigation.
• If the product uses sign-in, sign in and sign out using production callback/redirect settings. Confirm a signed-out visitor cannot access private rows.
• Add one practice record, refresh and read it back. Inspect the real hosted table to confirm it exists.
• Send invalid input: expect 400 and no new row. Simulate a failed request and confirm a helpful message instead of a blank panel.
• Resize to a narrow window and use Tab to reach the form and controls.

If the latest release breaks, use the host's documented rollback to a known working deployment while you diagnose. Reverting an application deployment does not reverse database changes. Preserve data and never delete a table as a quick rollback.

Before you call the product shipped

Explain where the page, endpoint and database run; demonstrate a persistent write and a rejected write on the deployed address; show which commit is live; and locate a safe error in the server log. These are learning checks, not new XP requirements. Keep the local build and deployment process in your project notes so you can repeat it for your next real product.