DEV Community: Thiago David

How to Securely Expose Your Jellyfin Using Oracle Cloud (Free Tier), Tailscale, and Nginx

Thiago David — Tue, 30 Jun 2026 23:47:52 +0000

If you have a Jellyfin media server at home, one of the biggest challenges is sharing access with friends or reaching your content while you're away. Opening ports on your home router is often impractical due to CGNAT, and it also exposes your home network to unnecessary risks.

In this guide, we'll set up an extremely secure and efficient architecture using only free tools:

Tailscale: Creates a secure private virtual network (Mesh VPN) between your home and the cloud.
Oracle Cloud (Free Tier): A free VPS that will serve as our public gateway to the internet.
Nginx: Will act as a Reverse Proxy on the VPS, managing SSL (HTTPS) certificates and forwarding streaming traffic in an optimized way.

Paid requirements:

Domain: You'll need to own a domain that you can use to expose Jellyfin access to the internet.

1. Tailscale Configuration

Tailscale will be responsible for invisibly connecting our Oracle VPS to your Jellyfin server at home.

Create an account at Tailscale.
Download and install the Tailscale client on the computer or server where your Jellyfin is running.
Follow the setup wizard to authenticate the device.
Note down the private IP address provided by Tailscale for your Jellyfin server (it will look something like 100.x.y.z).

⚠️ Important: just like we'll do later for the VPS, go to the Tailscale dashboard (login.tailscale.com), find this machine (your home Jellyfin server), and enable Disable key expiration. If only the VPS has this enabled and the home server's key expires, the connection drops on both ends anyway — the home server falls "off the network" even though the VPS is fine.

Step 1.1: Prepare the Jellyfin Host Firewall to Accept Tailscale Connections

Nginx will talk to Jellyfin through the Tailscale private IP (100.x.y.z:8096). If the home machine has a local firewall active, it can block that connection even though Tailscale itself is working fine — and this usually fails silently (timeout, no clear error).

If the Jellyfin server is on Linux (with ufw):

sudo ufw allow in on tailscale0

This allows all traffic arriving through the Tailscale interface, without needing to expose port 8096 to the local network or the internet.

If the Jellyfin server is on Windows:
In Windows Defender Firewall, create an Inbound Rule allowing TCP port 8096, restricting the Remote IP address to the Tailscale range (100.64.0.0/10). Alternatively, check that the "Tailscale" network adapter is classified as Private (not Public) in Windows network settings — this usually allows local traffic automatically for that profile.

2. Oracle Cloud Infrastructure (OCI) Configuration

Oracle offers excellent free instances on its Always Free Tier. Let's create our network infrastructure and virtual machine.

Step 2.1: Create the VCN (Virtual Cloud Network)

In the Oracle dashboard, go to Networking -> Virtual Cloud Networks.
Click Start VCN Wizard, select the default option with internet connectivity.
Keep the default settings, give it an easy-to-remember name, and complete the creation.

Step 2.2: Configure Ingress Rules (Cloud Firewall)

By default, Oracle blocks all external traffic. We need to allow access on the web and SSH ports.

Inside your VCN, go to Security Lists and click Default Security List for .
Click Add Ingress Rules and add the following two rules:

Rule 1: SSH Access

Source CIDR: 0.0.0.0/0
IP Protocol: TCP
Destination Port Range: 22

Rule 2: Web Traffic (HTTP/HTTPS)

Click Add Ingress Rules again.
Source CIDR: 0.0.0.0/0
IP Protocol: TCP
Destination Port Range: 80,443

Step 2.3: Create the Instance (VPS)

Go to Compute -> Instances -> Create Instance.
Select the Ubuntu operating system (latest LTS version) and choose the Always Free Eligible shape.
In the Networking section, select the VCN you just created.
Important: Expand the Advanced Options section at the bottom of the page and, in the Management / Cloud-init script field, paste the script below.

Why this script? Oracle's Ubuntu images come with very strict native iptables rules that block web traffic even after we open the ports in the dashboard. This script safely clears those rules at boot time.

#!/bin/bash
# Safely removes Oracle's native firewall at boot
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
netfilter-persistent save
systemctl stop netfilter-persistent
systemctl disable netfilter-persistent

Add your public SSH key so you can access the machine later, then click Create.
Wait until the instance switches to Running state and copy its Public IP Address.

3. DNS Configuration (Cloudflare)

For the SSL certificate to work correctly, you need your own domain pointing to your VPS.

Go to your DNS provider's dashboard (such as Cloudflare).
Create an A record (e.g., jelly.yourdomain.com) pointing to the public IP of the Oracle instance.

⚠️ Important (if using Cloudflare): leave the proxy disabled on this record (grey cloud — "DNS only", not the orange cloud). With Cloudflare's proxy enabled, Nginx sees Cloudflare's IP instead of the visitor's real IP, and video streaming can suffer from the free plan's size/timeout limits. Keep it on DNS only so the connection goes straight to your VPS.

4. VPS Configuration and Hardening

Now let's access the VPS via SSH to install Nginx, Tailscale, and Certbot. Replace ORACLE_IP with your virtual machine's public IP:

ssh ubuntu@ORACLE_IP

Step 4.1: Install and Configure UFW on the VPS

Instead of leaving the host firewall completely wide open (relying only on Oracle's Security List), let's install UFW and configure specific rules — this adds an extra layer of protection in case the Oracle network configuration changes in the future.

sudo apt install ufw -y

# Default policy: block incoming, allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH, HTTP and HTTPS
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow all traffic coming through the Tailscale interface
sudo ufw allow in on tailscale0

# Enable the firewall
sudo ufw enable

Note: install Tailscale (Step 4.3) before running ufw enable, otherwise the tailscale0 interface won't exist yet — in that case, just run sudo ufw allow in on tailscale0 again after installing Tailscale.

Step 4.2: Update the System and Install Fail2Ban

Make sure the server is up to date and protected against SSH brute-force attacks:

# Update repositories and packages
sudo apt update && sudo apt upgrade -y

# Install Fail2Ban for basic protection against SSH attacks
sudo apt install fail2ban -y

Step 4.3: Install and Authenticate Tailscale on the VPS

Now, let's bring the Oracle VPS into the same private network as your Jellyfin server at home:

# Automated Tailscale installation
curl -fsSL https://tailscale.com/install.sh | sh

# Authenticate the VPS to your Tailscale account
sudo tailscale up

Click the link generated in the terminal to authorize the new machine in the Tailscale dashboard.

⚠️ Very Important: Go to the Tailscale web dashboard (login.tailscale.com), find the machine corresponding to your Oracle VPS, click the three dots next to it, and select Disable key expiration. This prevents the connection from automatically dropping every 60 days.

If you installed UFW before Tailscale, run this now so the tailscale0 interface rule actually applies:

sudo ufw allow in on tailscale0

Step 4.4: Install Nginx and Certbot

Install the web server and the tool that automates the creation of our free Let's Encrypt SSL certificate:

sudo apt install nginx certbot python3-certbot-nginx -y

Step 4.5: Create the Initial Nginx Configuration (HTTP)

Let's create a temporary HTTP (port 80) configuration file just to let Certbot validate our domain.

sudo nano /etc/nginx/sites-available/jellyfin

Paste the following content, replacing YOUR_DOMAIN with your actual domain (e.g., jelly.yourdomain.com):

server {
    listen 80;
    listen [::]:80;
    server_name YOUR_DOMAIN;

    location / {
        return 301 https://$host$request_uri;
    }
}

Enable the configuration and restart Nginx:

# Create the symbolic link to enable the site
sudo ln -s /etc/nginx/sites-available/jellyfin /etc/nginx/sites-enabled/

# Remove the default Nginx configuration to avoid conflicts
sudo rm /etc/nginx/sites-enabled/default

# Test the syntax and restart the service
sudo nginx -t
sudo systemctl restart nginx

Step 4.6: Generate the SSL Certificate with Certbot

Run the command below to automatically generate the HTTPS certificate:

sudo certbot --nginx -d YOUR_DOMAIN

Follow the on-screen instructions, enter a valid email, and accept the terms of service.

Step 4.7: Final Optimized Reverse Proxy Configuration

With the certificate generated, let's replace the Nginx configuration file content to include Jellyfin streaming optimizations, WebSocket support, and security headers.

Open the file again:

sudo nano /etc/nginx/sites-available/jellyfin

Delete the old content and paste the full configuration below. Make sure to replace YOUR_DOMAIN with your domain and YOUR-JELLYFIN-SERVER-IP with the Tailscale private IP of your home server (noted in Step 1):

# BLOCK 1: HTTP (Port 80) redirect to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name YOUR_DOMAIN;

    return 301 https://$host$request_uri;
}

# BLOCK 2: HTTPS Reverse Proxy (Port 443)
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name YOUR_DOMAIN;

    # SSL CONFIGURATION (Automatically generated by Certbot)
    ssl_certificate /etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Essential Security Headers
    add_header X-Content-Type-Options "nosniff";

    # Access and Error Logs
    access_log /var/log/nginx/jellyfin.access.log;
    error_log /var/log/nginx/jellyfin.error.log;

    # Buffer and Timeout Optimization for Heavy Content
    proxy_connect_timeout 4s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;

    proxy_buffers 8 1024k;
    proxy_buffer_size 1024k;
    proxy_busy_buffers_size 2048k;
    client_max_body_size 100M;

    # Main route forwarded to the home Jellyfin server's Tailscale IP
    location / {
        proxy_pass http://YOUR-JELLYFIN-SERVER-IP:8096;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # CRUCIAL: Disabling proxy_buffering ensures video streaming
        # starts immediately without stutters caused by Nginx's buffer.
        proxy_buffering off;
    }

    # Dedicated route for Jellyfin WebSockets (real-time sync)
    location /socket {
        proxy_pass http://YOUR-JELLYFIN-SERVER-IP:8096;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # Extended timeout to prevent the persistent WebSocket connection from dropping
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Apply the changes and reload the service:

sudo nginx -t
sudo systemctl reload nginx

Conclusion

All set! From now on, when accessing https://your-domain.com, the connection will securely hit your Oracle VPS, pass through the encrypted Tailscale tunnel, and deliver the content directly from your home server with a valid SSL certificate and no open ports on your home router.

[Boost]

Thiago David — Fri, 21 Feb 2025 14:45:02 +0000

Carlos Henrique

Feb 21 '25

Hospedando seu site estático no Amazon S3 🚀

#aws #s3 #cloud #webdev

4 min read

Exposing Plex Application with Cloudflare Tunnel and Authenticate with Zero Trust

Thiago David — Mon, 10 Feb 2025 18:21:27 +0000

For tech enthusiasts who value practicality and organization when watching movies and series, this article is for you. Today, we'll discuss the Plex application, how to expose it to the internet (outside your local network), and how to protect it from unauthorized access using Cloudflare services.

Requirements

To ensure everything runs smoothly, the following prerequisites are essential:

A Cloudflare account.
A custom domain (e.g., mydomain.com).
Optional: A Google Cloud Console account (for Google login integration).

⚠️ Note: Cloudflare will need to control your domain's DNS. If you're currently using another provider (e.g., GoDaddy, Vercel, Netlify, etc.), you'll need to switch to Cloudflare for the services we'll use here.

What is Plex?

Plex is a media server application that allows you to organize, stream, and access your personal media library (movies, TV shows, music, photos, and videos) from anywhere. It functions as a media server installed on your computer or another compatible device, and a player that can be used on various devices such as smartphones, smart TVs, tablets, consoles, and browsers.

In essence, Plex consolidates all media from a specific device (typically a server) and serves it to other devices on the same network that have the Plex app installed.

What is Cloudflare?

Cloudflare is a company that offers a global network of services to improve the security, performance, and availability of websites, applications, and APIs. It acts as a CDN (Content Delivery Network) and a reverse proxy, protecting servers against attacks (e.g., DDoS) and speeding up page loading by caching content across multiple global locations.

Additionally, Cloudflare provides services such as fast and secure DNS, firewalls, load balancing, API security, corporate VPNs, and Zero Trust solutions.

Cloudflare Tunnel

The Cloudflare Tunnel is a service that allows you to securely expose internal applications or servers to the internet without opening firewall ports or using a public IP. It creates an encrypted tunnel between your local network and Cloudflare's infrastructure.

Zero Trust

Cloudflare Zero Trust is a security platform that implements the Zero Trust model, ensuring that no user, device, or network is automatically trusted. It protects access to internal applications, networks, and devices without relying on traditional VPNs.

With Cloudflare Zero Trust, businesses can control who accesses their systems, from where, and under what conditions, ensuring maximum security.

Getting Started

Let's begin by installing Plex on the computer that will serve as your media server.

Step 1: Create a Plex Account

Visit https://watch.plex.tv/pt/live-tv and complete the sign-up process.

Step 2: Download the Media Server

Once you have access to your account, go to https://www.plex.tv/pt-br/media-server-downloads/ and download the Plex Media Server. After downloading, follow the installation steps as you would for any other Windows program.

At this point, you'll have a Plex server running on your machine. After installation, Plex will likely redirect you to its dashboard. Here, you'll notice several options, such as Movies & Shows and Live TV. Personally, I tend to hide these since I don't use them.

Plex Configuration

Before moving on to Cloudflare, there are a few things you should be aware of to ensure your media appears in Plex.

Adding Media Libraries

To add your media directories, go to Settings -> Media Libraries -> Add Library. Here, you can define the type of library (movies, TV shows, etc.) and select the desired folder path. Save your changes.

If you don't see any movies or TV shows in Plex, there are two things you can check:

1. Enable Automatic Media Scanning

Go to Settings -> Libraries. You'll see two options: Scan my library automatically and Scan my library periodically. Enable both to ensure new media is detected and added to Plex.

2. Folder Structure

Plex expects a specific folder structure to properly index and fetch metadata for your media.

You can refer to Plex's official articles on organizing movies and TV shows. Below is a basic example:

Movies:

Pattern: /Movies/MovieName (release year)/MovieName (release year).extension
Example:

/Movies
    /Avatar (2009)
      Avatar (2009).mkv
    /Batman Begins (2005)
      Batman Begins (2005).mp4
      Batman Begins (2005).en.srt
      poster.jpg

Tv Shows:

Pattern: /Series/SerieName (release year)/Season (season number)/S01E01 - Name.extension
Example:

/TV Shows
   /Doctor Who (1963)
      /Season 01
         Doctor Who (1963) - s01e01 - An Unearthly Child (1).mp4
         Doctor Who (1963) - s01e02 - The Cave of Skulls (2).mp4
   /From the Earth to the Moon (1998)
      /Season 01
         From the Earth to the Moon (1998) - s01e01.mp4
         From the Earth to the Moon (1998) - s01e02.mp4
   /Grey's Anatomy (2005)
      /Season 00
         Grey's Anatomy (2005) - s00e01 - Straight to the Heart.mkv
      /Season 01
         Grey's Anatomy (2005) - s01e01 - pt1.avi
         Grey's Anatomy (2005) - s01e01 - pt2.avi
         Grey's Anatomy (2005) - s01e02 - The First Cut is the Deepest.avi
         Grey's Anatomy (2005) - s01e03.mp4
      /Season 02
         Grey's Anatomy (2005) - s02e01-e03.avi
         Grey's Anatomy (2005) - s02e04.m4v
   /The Colbert Report (2005)
      /Season 08
         The Colbert Report (2005) - 2011-11-15 - Elijah Wood.avi
   /The Office (UK) (2001) {tmdb-2996}
      /Season 01
         The Office (UK) - s01e01 - Downsize.mp4
   / The Office (US) (2005) {tvdb-73244}
      /Season 01
         The Office (US) - s01e01 - Pilot.mkv

Cloudflare Setup

Now that your Plex server is running and your media is accessible on your local network, let's move on to exposing it to the internet using Cloudflare.

Step 1: Create a Cloudflare Account

Visit https://dash.cloudflare.com/login and complete the sign-up process. Once done, you'll be redirected to the Cloudflare dashboard. On the home screen, you'll be prompted to add and configure your domain's DNS settings with Cloudflare.

Follow the steps provided by Cloudflare to adjust your DNS settings.

Step 2: Zero Trust Dashboard

After configuring your domain, navigate to the Zero Trust Dashboard (accessible via the sidebar or directly at https://one.dash.cloudflare.com/). On your first visit, you'll be asked to create a "team name." Remember this name, as we'll use it later for Google integration.

Select the plan that suits your needs. For this guide, we'll use the free plan, which is sufficient for our purposes. Cloudflare will ask for a credit card, similar to other providers like AWS or DigitalOcean.

Step 3: Create a Tunnel

To configure the tunnel, follow these steps:

In the sidebar, expand the Networks menu and click on Tunnels.
Click Create Tunnel, give it a name, and follow the installation and activation steps for the cloudflared adapter.
In Public Hostnames, specify a subdomain (e.g., plex.mydomain.com) and select your domain.
Under Service, choose the http protocol and point it to your local Plex server at localhost:32400.

If everything is set up correctly, the tunnel status will show as Healthy.

At this point, you can access your Plex server via the URL you specified. However, this leaves your server open to anyone, which is not ideal for privacy or performance. Let's secure it further.

Access Control with Zero Trust

To ensure only authorized users can access your Plex server, we'll use Cloudflare's Access feature.

Google Authentication (Optional)

If you want to integrate Google login, follow these steps:

Visit the Google Cloud Platform console. Create a new project, name the project, and select Create.
On the project home page, go to APIs & Services on the sidebar and select Dashboard.
On the sidebar, go to Credentials and select Configure Consent Screen at the top of the page.
Choose External as the User Type. Since this application is not being created in a Google Workspace account, any user with a Gmail address can login.
Name the application, add a support email, and input contact fields. Google Cloud Platform requires an email in your account. Note: In the Scopes section, we recommend adding the userinfo.email scope. This is not required for the integration, but shows authenticating users what information is being gathered. You do not need to add test users.
Return to the APIs & Services page, select Create Credentials > OAuth client ID, and name the application.
Under Authorized JavaScript origins, in the URIs field, enter your team domain:
```
https://<your-team-name>.cloudflareaccess.com
```
You can find your team name in Zero Trust under Settings > Custom Pages.
Under Authorized redirect URIs, in the URIs field, enter the following URL:
```
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
```
Google will present the OAuth Client ID and Secret values. The secret field functions like a password and should not be shared. Copy both values.

Next, go to the Zero Trust dashboard, navigate to Settings -> Authentication, and add a new login method using the Google credentials you just created.

User Lists

Before creating access policies, let's create a list of pre-approved users:

Go to My Team -> Lists and click Create Manual List.
Name the list (e.g., Plex Users), set the type to User Emails, and add the emails of authorized users.

Access Policies

We are in the final stage, and now we will create our policies, which are essentially the rules that users attempting to access the application must follow. In this step, we will create two policies. One to ensure that users listed in our previously created list have unrestricted access.

Creating the First Policy

Go to access -> policies in the Zero Trust dashboard and click on Create policy.
In this first policy, we will specify that any user who logs in with the email specified in the list created earlier will have free access. Choose a name that aligns with the policy (e.g., pre-approved users).
In Action, select Allow, and the session duration is up to you.
Under Rules, keep only one instruction of Include. In the selector, choose Email List (if you haven’t created the list, you can simply select Emails), and in the value field, choose your list.

You can save and create a new policy.

Creating the Second Policy

For this new policy, specify a name related to requesting access.
In Action, define Allow.
Under Rules, add the selector Login Methods, and in the value, specify Google and One-time Pin. These methods may vary depending on your needs. If you haven't integrated with Google, you can select only the Pin.
To ensure users not on our pre-approved lists can request access, check the Purpose justification checkbox. Optionally, provide a message for users to explain why they need access. Then, check the Temporary authentication checkbox and provide your email or the email of the person responsible for approving new user access. It is important to note that new users who go through this requested access stage cannot have indefinite access (usually, it allows access for up to 1 day). Therefore, I recommend that if you want to grant permanent access, add their email to the list we created earlier.

After saving the policy, we can proceed to the final stage.

Final Steps: Creating the Application

To apply these policies to your Plex server:

Go to Access -> Applications.
Click Add an Application and select Self-Hosted.
Name your application and specify the same URL used in your tunnel.
Under Access Policies, select the two policies you created, ensuring the pre-approved policy is evaluated first.

Conclusion

Congratulations! Your Plex server is now securely exposed to the internet, with controlled access to ensure only authorized users can stream your media. This setup combines the convenience of Plex with the robust security of Cloudflare, giving you peace of mind and a seamless streaming experience. Enjoy your media library from anywhere!

Protecting sveltekit routes from unauthenticated users

Thiago David — Mon, 27 Nov 2023 21:17:59 +0000

While developing a SvelteKit app, I found myself contemplating the intricacies of authentication, specifically regarding the proper storage of user session data and securing access to private routes. In my case, I was working with a Rails API handling user registration and authentication through Devise JWT. I opted not to use any ORMs (such as Prisma or Sequelize).

As I delved into the available resources, I came across articles detailing route protection using cookies and hooks. However, adapting their code to meet my specific needs proved challenging. My requirements included integrating a Rails API for user management, avoiding the use of ORMs, and ensuring secure handling of sensitive data.

In this article, I'll guide you through handling user session data and implementing routing protection in such a scenario.

Understanding HTTP Cookies

HTTP Cookies are familiar components for anyone who has traversed websites. Essentially, cookies are small files stored in browsers, typically containing information like authentication tokens or session data. To enhance security, we prefer not to store sensitive data directly in cookies. This concern led to the introduction of HTTPOnly Cookies, which ensures that the server receives the cookie with each specific request, while JavaScript remains unable to access it.

Unpacking SvelteKit Hooks

SvelteKit Hooks, according to the documentation, are app-wide functions that you declare, and SvelteKit calls them in response to specific events. This grants you fine-grained control over the framework's behavior. Leveraging hooks allows us to exercise control over each request passing through our application, enabling us to capture the pathname of the URL the user is attempting to access. This capability proves crucial for redirecting unauthenticated users.

Implementation Steps

Before diving into the implementation details, I assume you already have an external API application, like a Rails or Node.js server, up and running. This allows us to focus more on the SvelteKit implementation. Let's proceed by creating a new SvelteKit app using npm.

npm create svelte@latest sveltekit-auth
cd sveltekit-auth
npm install

Now that we have the initial structure in place, let's create some basic forms for testing authentication. We'll create three new routes: signin, signup, and logout.

on the signin and signup i will create two files.

+page.svelte
+page.server.js

and on the logout i will only create one file, the +page.server.js.

the structure it will be like that:

Before delving into the code for these files, let's create a SvelteKit store to maintain user data in runtime memory. Inside the src/lib folder, create a store folder, and within it, a file named user.js.

Inside user.js, add the following code:

// src/stores/user.js
import { writable } from "svelte/store";

export const user = writable({
  email: "",
  name: "",
})

This store provides a global object to access and manipulate user data.

Next, let's create basic forms for signup and signin. These forms are simple for testing purposes and lack styling for simplicity.

<!-- signup/+page.svelte -->
<h1>This is the Signup page</h1>
<form action="/signup" method="POST">
  <input type="text" name="name" placeholder="Name">
  <input type="text" name="email" placeholder="email" />
  <input type="password" name="password" placeholder="Password" />
  <button type="submit">Sign up</button>
</form>

signin page:

<!-- signin/+page.svelte -->
<h1>This is the signin page</h1>
<form action="/signin" method="POST">
  <input type="text" name="email" placeholder="email" />
  <input type="password" name="password" placeholder="Password" />
  <button type="submit">Sign in</button>
</form>

Notice that we retained the initial +page.svelte in the root route (http://localhost:5173/). Why? We'll treat it as a "private" page that doesn't accept access from unauthenticated users. In this file, we'll set up the following code:

<!-- routes/+page.svelte -->
<h1>This will be our protected page</h1>
<form action="/logout" method="post">
  <button>Logout</button>
</form>

Now, let's set up the server files for each route. For the signup route, create +page.server.js:

// signup/+page.server.js
import { user } from '$lib/stores/user.js'
import { redirect } from '@sveltejs/kit'

//create a new action called default passing the cookies, request and fetch as parameters
export const actions = {
  default: async ({ cookies, request, fetch}) => {
    //retrieve the form data from the request and set it to the variables
    const data = await request.formData()
    const email = data.get('email')
    const password = data.get('password')
    const name = data.get('name')

    //check if the variables are valid and if not, return an error
    if (
            typeof email !== 'string' ||
            typeof password !== 'string' ||
            !email ||
            !password
        ) {
            return {
        status: 400,
        body: {
          success: false,
        }
      }
        }

    //send the data to the backend API (use your endpoint in this case)
    const response = await fetch('http://localhost:3000/users', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        user: {
          email,
          password,
          name
        }
      })
    })

    //if the response is ok, set the cookies and redirect to the homepage
    if (response.ok) {
      const data  = await response.json()
      //setting the cookies of user and jwt
      cookies.set('user', JSON.stringify(data.user))
      cookies.set('jwt', response.headers.get('Authorization'))
      let obj = {
        ...data,
        jwt: response.headers.get('Authorization')
      }
      user.set(obj)

      //redirect user to the protected page
      throw redirect(302, '/')
    } else {
      //if the response is not ok, return the errors
      const { errors } = await response.json()
      return {
        status: 400,
        body: {
          success: false,
          errors
        }
      }
    }
  }
}

For the signin route, create +page.server.js:

// signin/+page.server.js
import { user } from '$lib/stores/user.js'
import { redirect } from '@sveltejs/kit'

export const actions = {
  default: async ({ cookies, request, fetch}) => {
    const data = await request.formData()
    const email = data.get('email')
    const password = data.get('password')

    if (
            typeof email !== 'string' ||
            typeof password !== 'string' ||
            !email ||
            !password
        ) {
            return {
        status: 400,
        body: {
          success: false,
        }
      }
        }

    const response = await fetch('http://localhost:3000/users/sign_in', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        user: {
          email,
          password
        }
      })
    })

    if (response.ok) {
      const data  = await response.json()
      cookies.set('user', JSON.stringify(data.user))
      cookies.set('jwt', response.headers.get('Authorization'))
      let obj = {
        ...data,
        jwt: response.headers.get('Authorization')
      }
      user.set(obj)

      throw redirect(302, '/')
    } else {
      const { errors } = await response.json()
      return {
        status: 400,
        body: {
          success: false,
          errors
        }
      }
    }
  }
}

Finally, for the logout route, create +page.server.js:

// logout/+page.server.js
import { redirect } from '@sveltejs/kit'

export const actions = {
  default: async ({ cookies}) => {
    //set the cookies to null and redirect
    cookies.set('user', null)
    throw redirect(302, '/')
  }

}

Now, let's implement the hook. Create a new file, hooks.server.js, in the src folder.

// src/+hooks.server.js
import { redirect } from "@sveltejs/kit";

// define the routes of we want to be possible to access without auth
const public_paths = [
  '/signup',
  '/signin'
];

// function to verify if the request path is inside the public_paths array
function isPathAllowed(path) {
  return public_paths.some(allowedPath =>
    path === allowedPath || path.startsWith(allowedPath + '/')
  );
}

export const handle = async ({ event, resolve}) => {
  let user = null
  // check if the cookie exist, and if exists, parse it to the user variable
  if(event.cookies.get('user') != undefined && event.cookies.get('user') != null){
    user = JSON.parse(event.cookies.get('user'))
  }
  const url = new URL(event.request.url);

  // validate the user existence and if the path is acceesible
  if (!user && !isPathAllowed(url.pathname)) {
    throw redirect(302, '/signin');
  }

  if(user){
    //set the user to the locals (i explain this later on the article)
    event.locals.user = user

    // redirect user if he is already logged if he try to access signin or signup
    if(url.pathname == '/signup' || url.pathname == '/signin'){
      throw redirect(302, '/')
    }
  }

  const response = await resolve(event)

  return response
}

This hook captures every request passing through the application. Using the handle function, we access the cookies set previously, determine whether the user should be redirected, and set the user store again. Note the use of event.locals to pass user data through server-side functions with the request.

On the routes folder, create the follow files

+layout.svelte
+layout.server.js

on the +layout.svelte set the code:

<!-- routes/+layout.svelte -->
<script>
  import { user } from '$lib/stores/user.js'
  export let data
  $user = data.user
</script>
<!-- i will put that for it can be possible to see the user data consistance -->
<h1>User info :</h1>
<pre>{JSON.stringify($user, null, 2)}</pre>
<slot />

and the last one, the +layout.server.js:

// routes/+layout.server.js
export const load = async ({ locals }) => {
    return {
        user: locals.user,
    }
}

Now, you can test the implementation. Attempting to access the protected route (/) without signing in will redirect you to the signin page.

Conclusion

In this article, I aimed to simplify the understanding of authentication flow and the use of hooks in SvelteKit. Having encountered some difficulties myself in grasping these features, I hope this guide proves helpful for your understanding as well.