Supabase Auth and Prisma Integration

Why This Integration?

Integrating Supabase Auth with Prisma offers a robust solution for managing user authentication alongside extended user profiles within a single application. While Supabase Auth provides a secure and scalable authentication system, it limits user-related data to basic information. By synchronizing auth.users with a custom public.users table managed by Prisma, we gain the flexibility to extend user profiles with additional fields and maintain referential integrity through foreign keys, enhancing our application’s data model and capabilities.

How It Works


This integration automatically mirrors entries from Supabase’s auth.users table to a custom public.users table in our database. This synchronization allows us to extend the user model with additional information (e.g., user settings) and establish foreign key relationships with other tables, all managed through Prisma.

Step 1: Setting Up Prisma

Define your User model in schema.prisma to mirror Supabase’s auth.users and include additional fields:

model User {
  id        String   @id @default(uuid()) @map("id")
  email     String   @unique
  settings  Json?
  createdAt DateTime @default(now()) @map("created_at")
  updatedAt DateTime @updatedAt @map("updated_at")


Step 2: Creating a PostgreSQL Trigger in Supabase

Implement a PostgreSQL trigger within Supabase to sync every new or updated entry in auth.users with public.users:

CREATE OR REPLACE FUNCTION public.handle_user_sync()
    INSERT INTO public.users (id, email, created_at, updated_at)
    VALUES (,, NOW(), NOW())
    UPDATE public.users
    SET email =, updated_at = NOW()
    WHERE id =;
$$ LANGUAGE plpgsql;

CREATE TRIGGER sync_auth_users
FOR EACH ROW EXECUTE FUNCTION public.handle_user_sync();

Step 3: Managing User Data with Prisma

With the synchronization in place, use Prisma to manage public.users, adding any additional user-related data or settings as needed.

Security and Performance

  • Ensure sensitive user information is securely handled and access-controlled.
  • Monitor the performance impact of the database trigger, adjusting as necessary.


Before deployment, thoroughly test the integration in a development environment to confirm that user data syncs correctly and that your application logic functions as expected.


This README outlines the integration of Supabase Auth with Prisma for enhanced user data management. By leveraging the strengths of both platforms, we create a powerful foundation for building sophisticated and scalable applications.

Setting Up a PXE Boot Server with Using Dnsmasq on Ubuntu


In this blog post, we’ll guide you through setting up a PXE (Preboot Execution Environment) boot server with on Ubuntu, leveraging dnsmasq for a simplified setup. This configuration allows networked machines to boot various operating systems from a single server, ideal for labs, data centers, or rapid OS deployments.

What is PXE Booting?

PXE booting enables computers to load and boot an operating system from a network server. This method is extensively used for system installations, recovery, and testing different operating systems without local storage.

Why is an open-source initiative that simplifies the PXE boot process with a dynamic boot menu, allowing selection from a range of operating systems and tools. This capability is crucial for efficient network and system management.

Why dnsmasq?

It supports DHCP and TFTP services, which is a more streamlined approach for setting up a PXE boot environment. Alternatively you can use isc-dhcp-server and tftpd-hpa.


  • An Ubuntu 22.04 server (referred to as pxehost).
  • Basic Linux and network configuration knowledge.
  • Root or sudo privileges on the server.

Step 1: Installing Dnsmasq

Dnsmasq serves as both the DHCP and TFTP server, streamlining the setup. Install it using:

sudo apt-get update sudo apt-get install -y dnsmasq

Step 2: Configuring Dnsmasq

Edit /etc/dnsmasq.conf to include DHCP and TFTP settings:

sudo nano /etc/dnsmasq.conf

Add the following configuration:

# DHCP Settings dhcp-range=,,,24h dhcp-option=option:router, dhcp-option=option:dns-server,localhost, # TFTP Settings enable-tftp tftp-root=/var/lib/tftpboot

Restart dnsmasq to apply the changes:

sudo systemctl restart dnsmasq

Step 3: Setting Up

Download the boot files into the TFTP directory:

sudo mkdir -p /var/lib/tftpboot cd /var/lib/tftpboot sudo wget sudo wget

Step 4: Testing the PXE Boot and Troubleshooting

Test the PXE boot on a client machine. If issues arise, check the dnsmasq logs:

bashCopy code

grep dnsmasq /var/log/syslog

For TFTP issues, attempt a manual TFTP download from another machine:

bashCopy code

tftp get quit

Confirm that the TFTP server is correctly configured and accessible.


Using dnsmasq for PXE booting with offers a streamlined, efficient approach to network booting. This setup is ideal for environments requiring quick and versatile OS deployments and system management.

How to Set Up Split DNS Configuration on macOS for Specific Domains


For someone who needs to direct traffic for specific domains to a particular server, setting up a split DNS configuration on macOS is a straightforward way to achieve this. Today, we’ll explore how to resolve all domains ending in .sf through a designated DNS server at

What is Split DNS?

Split DNS is a configuration where DNS queries for specific domains are handled by a designated DNS server, while all other queries go through the default DNS settings. This setup is particularly useful in development environments or for internal network purposes.

Setting Up Split DNS on macOS

To set up a split DNS configuration on macOS, we’ll use the built-in resolver feature. Here’s how:

Step 1: Create a Resolver Directory

Open Terminal and create a directory for resolver if it doesn’t already exist:

bashCopy code

sudo mkdir -v /etc/resolver

Step 2: Create a Resolver File

In /etc/resolver/, create a file named sf:

bashCopy code

sudo nano /etc/resolver/sf

Add the following line to specify the DNS server:Copy code


Save and exit the editor.

Step 3: Flush DNS Cache

Flush the DNS cache to ensure your changes take effect:

bashCopy code

sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder

Testing Your Configuration

After setting up, test it with nslookup or dig:

bashCopy code

nslookup example.sf

The server should now point to


If the DNS queries are still being resolved by the default server (like Google’s, here are some things to check:

  • Correct File and Syntax: Ensure /etc/resolver/sf is correctly set up.
  • Permissions: Verify the file’s permissions and ownership.
  • Direct Testing: Query the DNS server directly with dig @ example.sf.
  • Network Connectivity: Confirm that is reachable and correctly configured.
  • Restart Network Services: Sometimes, toggling network services can help.
  • Reboot: When in doubt, reboot!