Two Laptops, One Codebase: The Full Stack Hack You Didn’t Know You Needed

As full stack developers, it's not uncommon to juggle multiple projects—and often, multiple devices. Many of us work with more than one laptop, yet still run both the frontend and backend of our applications on a single machine. This setup can become resource-intensive and inefficient, especially when dealing with large codebases or memory-hungry environments.

Split Stack Setup

In this article, I’ll share a simple but powerful workflow: running the backend on one laptop and the frontend on another. By separating these layers, you not only free up resources but also create a cleaner development experience. This setup allows you to focus entirely on frontend development while still connecting to a live, running API—mirroring real-world deployment conditions more closely.

For the purpose of this article, I’ll be using Ruby on Rails for the backend and React for the frontend, as they are my primary tools. However, the principles and workflow outlined here are stack-agnostic—you can easily adapt this approach to any combination of backend and frontend technologies.

The core idea is to enable seamless communication between two machines over a local network: one serving the backend API, and the other running the frontend interface. This setup can significantly streamline your development process by distributing the workload across devices.

Let’s walk through the setup, step by step.

Overview:

  • Laptop A: React frontend (e.g. Vite or Create React App)
  • Laptop B: Rails backend (API) They'll communicate over your local network using the IP address of Laptop B (the one running Rails).

Prerequisites

  1. Both laptops are on the same Wi-Fi or LAN.
  2. Backend API must be CORS-enabled to allow requests from the frontend.
  3. React app should point to backend using the local IP of Laptop B.
  4. Firewall rules must allow incoming connections (or be temporarily disabled for testing).

Step-by-Step Setup

On Laptop B (Rails Backend)

  1. Find local IP address Run in terminal:
ipconfig    # On Windows
ifconfig    # On macOS/Linux

Let’s assume it’s:

192.168.1.10
  1. Start Rails server bound to 0.0.0.0 Run:
rails server -b 0.0.0.0 -p 3000
This allows access from any device on the network.
  1. Add CORS support (if not already) In your Rails app, edit config/initializers/cors.rb:
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*',
      headers: :any,
      methods: [:get, :post, :patch, :put, :delete, :options]
  end
end

✅ In production, replace '*' with the actual origin for security.

On Laptop A (React Frontend)

  1. Update API endpoint in React Use http://192.168.1.10:3000 wherever you call the Rails backend.

Example:

fetch('http://192.168.1.10:3000/api/v1/something')
  1. Start React app If using Vite:
npm run dev -- --host

If using Create React App:

npm start

This makes the dev server accessible to other devices (useful for debugging on phones too).

Test

Visit your React frontend (on Laptop A).

Open the browser dev tools.

Make sure API requests go to 192.168.1.10:3000 and get successful responses.

Security Tips

  • Never expose 0.0.0.0 to public internet without authentication.
  • For development, it’s OK to use open CORS and IP binding, but in production:
    • Use environment-based whitelisting
    • Secure connections with HTTPS
    • Authenticate requests (e.g., JWT, sessions)

While running your frontend and backend on separate machines can greatly improve development efficiency, it’s crucial to consider network security—especially during local development.

Always make sure both machines are connected to a private, trusted local network (such as your home Wi-Fi or a secure office LAN). Avoid using public or unsecured networks for this setup, as exposing your backend API to a public IP—even unintentionally—can lead to serious vulnerabilities, including unauthorized access or data leaks.

This workflow is intended for local development only, and best practices like firewall rules, private IP addressing, and machine-specific access should always be in place. Keep your setup isolated and secure, just as you would in a production environment.

By staying on a private network, you get all the performance and flexibility benefits—without compromising on safety.