Vite manifest not found at: /var/www/your-app/public/build/manifest.json

Locally everything is fine, because there you either have npm run dev running or you ran npm run build at some point. On the server, the file Laravel is looking for simply isn't there. Laravel's "Vite manifest not found" error is not a framework bug. It means the frontend build output (the public/build folder) was never created, or was created somewhere Laravel isn't looking. This guide first shows exactly where the error comes from, then walks through three real ways to build your assets and get them onto the server: building on the VPS itself, building in GitHub Actions, and building on your own machine for shared hosting without Node.

Where exactly does this error come from?

In Blade you load your assets with the @vite directive:

<head>
    @vite(['resources/css/app.css', 'resources/js/app.js'])
</head>

According to the official Laravel Vite documentation:

The @vite directive will automatically detect the Vite development server and inject the Vite client to enable Hot Module Replacement. In build mode, the directive will load your compiled and versioned assets, including any imported CSS.

So @vite has two modes:

1. Dev mode: if a public/hot file exists (npm run dev creates it), Laravel doesn't touch the manifest at all. It points the tags at the dev server URL written inside that file (for example http://localhost:5173).
2. Build mode: if there's no public/hot, Laravel reads public/build/manifest.json to find out which hashed file (for example assets/app-xxxx.js) resources/js/app.js was built into.

The exception itself is thrown by the Illuminate\Foundation\Vite class (the class behind @vite and the Vite facade), in its manifest() method. A trimmed version of the framework code:

protected function manifest($buildDirectory)
{
    $path = $this->manifestPath($buildDirectory);

    if (! isset(static::$manifests[$path])) {
        if (! is_file($path)) {
            throw new ViteManifestNotFoundException("Vite manifest not found at: $path");
        }

        static::$manifests[$path] = json_decode(file_get_contents($path), true);
    }

    return static::$manifests[$path];
}

A few things follow from those lines:

• The path is built from public_path() + the build directory (default build) + the manifest filename (default manifest.json). So the path in the error message is exactly where Laravel looked. Your first job is to compare it with where your build actually lives.
• Since Laravel 11, ViteManifestNotFoundException extends ViteException (and is marked deprecated in the source), so catching ViteException also catches this one.
• If you changed the build directory (for example with Vite::useBuildDirectory('bundle') or the second argument of @vite), Laravel looks for public/bundle/manifest.json. useBuildDirectory() doesn't throw anything itself; it only changes the path. If vite.config.js (the Laravel plugin's buildDirectory option) doesn't use the same value, the manifest ends up somewhere else and you get this error.

Two similar errors that often get mixed up with this one:

Why does it work locally but not on the server?

The usual causes:

1. public/build never reached the server. Laravel's default .gitignore contains both /public/build and /public/hot. If your deploy is just git pull, the build never travels with the code and has to be produced somewhere else.
2. The build exists, but in the wrong place. Most common on shared hosting: you copied the contents of public into public_html, but Laravel's public_path() still points to .../your-app/public.
3. The build ran on the server but failed. For example Node is too old, or dependencies were installed without devDependencies. If vite build exits with an error, no manifest is written.

There's also one case that does not throw this error but is often confused with it: a leftover public/hot file on the server. Then Laravel skips the manifest and points the tags at the dev server (for example localhost:5173). You get a page with no CSS or JS, not a manifest error. It usually happens when someone ran npm run dev on the server or uploaded the hot file by hand.

Diagnose first: where is the manifest?

Before touching CI or config, run these from the project root on the server:

# 1. Does the build folder exist?
ls -la public/build/

# 2. Is manifest.json there, and does it have content?
head -c 500 public/build/manifest.json

# 3. Is a hot file (dev server) left behind?
ls -la public/hot 2>&1

# 4. Which path exactly is Laravel looking at?
php artisan tinker --execute="echo public_path('build/manifest.json');"

How to read the results:

• No public/build: the build never ran or never reached the server. Pick one of the three fixes below.
• The folder exists but the manifest is missing or empty: the build failed partway. Read the full npm run build output (see "Common errors").
• The path from command 4 differs from where you put the build: it's a public path problem (see the shared hosting section).
• public/hot exists: delete it. It has no purpose in production:

rm -f public/hot

Another quick check: open https://your-domain.com/build/manifest.json in a browser. The file is public, so if it's in place you'll see JSON; a 404 means it isn't in the public folder your web server serves.

Which fix fits your setup?

Rule of thumb: if Node is on the server, build there. If it isn't, or you want every deploy to be reproducible, use CI. If neither is available, build on your own machine.

Fix 1: Build on the VPS

Install the right Node version

First check whether Node is installed at all. Ubuntu and Debian don't ship it by default, and the version in the default repositories may be too old for Vite:

node --version
npm --version

According to the Vite docs, Vite requires Node.js 20.19+ or 22.12+ (Laravel 12's default package.json uses Vite 7, Laravel 13's uses Vite 8). Node 20 also reached end of life in April 2026 according to the Node.js release table, so use an active LTS such as 22 or 24 on the server. With nvm:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh | bash
source ~/.bashrc
nvm install 24

(Check nvm's README for the latest script version before running it.)

Run the build

# On the server, inside the project root
cd /var/www/your-app

# Install exact dependencies from package-lock.json
npm ci --no-audit --no-fund

# Production build
npm run build

⚠️ Don't add --omit=dev or NODE_ENV=production here. In Laravel's default package.json, vite, laravel-vite-plugin and tailwindcss are all devDependencies; if they aren't installed, the build dies with Cannot find module.

A successful run looks something like this (version, hashes and sizes will differ in your project):

vite v7.x.x building for production...
✓ NN modules transformed.
public/build/manifest.json             x.xx kB │ gzip: x.xx kB
public/build/assets/app-[hash].css    xx.xx kB │ gzip: x.xx kB
public/build/assets/app-[hash].js     xx.xx kB │ gzip: xx.xx kB
✓ built in x.xxs

If there's no public/build/manifest.json line, or the build ended with an error, no manifest was written.

What needs to be on the server?

After the build, only these matter:

public/build/manifest.json
public/build/assets/   (hashed CSS and JS files)

node_modules is only needed to produce the build; Laravel doesn't use it at runtime.

Checklist before you call the deploy done

# ✓ Is the manifest there?
test -f public/build/manifest.json && echo "OK" || echo "MISSING"

# ✓ Was at least one CSS or JS file built?
ls public/build/assets/ | grep -E '\.(css|js)$' > /dev/null && echo "OK" || echo "EMPTY"

# ✓ Is the hot file gone?
test ! -f public/hot && echo "OK" || echo "HOT FILE EXISTS"

# ✓ Owner and permissions
ls -l public/build/manifest.json

The owner doesn't have to be www-data. What matters is that the PHP-FPM user and the web server can read the files (for example 644 for files and 755 for directories is enough).

Fix 2: Build in GitHub Actions

If you want every deploy built from the same clean environment, or you don't want Node on the server, let CI do the build. This section only covers building and shipping public/build; the deploy user, SSH keys and secrets are assumed to be set up already.

The workflow

# .github/workflows/deploy.yml
name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '24'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build assets
        run: npm run build
        # If your JS uses VITE_ variables, provide them here:
        # env:
        #   VITE_APP_NAME: ${{ vars.VITE_APP_NAME }}

      - name: Verify manifest exists
        run: |
          test -f public/build/manifest.json || (echo "Manifest missing!" && exit 1)
          test -d public/build/assets || (echo "Assets dir missing!" && exit 1)

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: vite-build
          path: public/build
          retention-days: 7

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: vite-build
          path: public/build

      - name: Upload build to server
        uses: appleboy/scp-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          source: "public/build"
          target: "/var/www/your-app/public/build-new"
          strip_components: 2
          rm: true

      - name: Swap build on server
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            set -e
            cd /var/www/your-app
            test -f public/build-new/manifest.json
            rm -rf public/build-old
            if [ -d public/build ]; then mv public/build public/build-old; fi
            mv public/build-new public/build
            rm -f public/hot

A few notes on this workflow:

• Verification runs before the upload. If no manifest was built, the first job fails and the deploy job never runs, so the site never goes live without a manifest.
• The build is uploaded to build-new first and then swapped in with mv. If you rm -rf public/build and then upload, the site runs without assets for a while. The previous build stays in build-old, so a cached page that still points to old hashes doesn't get 404s.
• VITE_ variables are baked into the JS at build time, not at runtime. If you use import.meta.env.VITE_..., they must have values in this step (Vite docs on env variables).
• If you want zero half-finished states, swap the whole release with a symlink (atomic deploy) instead of just the build folder.
• If you run Laravel Octane, the manifest is cached in a static property and workers live between requests; reload them after deploy with php artisan octane:reload.

Tests in CI throw the same error

If your CI runs PHPUnit or Pest before building, and a test renders a view that uses @vite, you'll get the same Vite manifest not found. According to the Laravel docs, either run npm run build before the tests or call $this->withoutVite() in your tests.

Cost

According to GitHub's Actions billing docs, standard GitHub-hosted runners are free for public repositories. Private repositories get a monthly quota depending on the plan (for example, GitHub Free includes 2,000 minutes and 500 MB of artifact storage per month). The retention-days: 7 above keeps old artifacts from eating that storage.

Fix 3: Build locally and upload public/build (shared hosting without Node)

Many shared hosts give you neither Node nor full SSH. In that case you build on your own machine and upload only the output.

Build locally

# On your machine, inside the project root
node --version    # an active LTS, e.g. 22 or 24

npm ci
npm run build

# Compress the output
cd public
zip -r build.zip build/

If you have a public/hot file locally (because npm run dev is running), make sure you don't upload it along with everything else.

Upload

Through the panel's File Manager or SFTP:

1. Upload build.zip into the same public folder Laravel actually uses.
2. Extract it so you get build/manifest.json and build/assets/.
3. Delete the zip file.

The key point: the public path on shared hosting

A common layout is Laravel's code in /home/user/your-app and the site's web root in public_html. If you copied the contents of public into public_html, Laravel still thinks public_path() is /home/user/your-app/public and looks for /home/user/your-app/public/build/manifest.json; the error message shows exactly that path.

You have two options:

• put the build where the error message says, or
• tell Laravel where the real public folder is. On Laravel 11+, in bootstrap/app.php:

$app = Application::configure(basePath: dirname(__DIR__))
    // ->withRouting(...) and the rest of your current config
    ->create();

// Adjust the path to match your host's layout
$app->usePublicPath(dirname(__DIR__, 2).'/public_html');

return $app;

Checklist without SSH

• In File Manager, check that build/manifest.json and the build/assets/ folder sit next to the site's index.php.
• Open https://your-domain.com/build/manifest.json in a browser; you should see JSON.
• Make sure there's no file called hot next to index.php.

You don't need to upload node_modules, package.json or package-lock.json; they play no role at runtime.

Comparing the three methods

Common errors and fixes

Error 1: EACCES: permission denied, mkdir '/var/www/.npm'

This usually shows up when you run npm as the web server user (for example sudo -u www-data npm ci). That user's home is usually /var/www, which it can't write to, so npm can't create its .npm cache folder.

# Better: run the build as the deploy user that owns the project
cd /var/www/your-app
npm ci
npm run build

# Or, if you must run it as another user, change the cache path for that run
npm ci --cache /tmp/npm-cache

Error 2: Cannot find module 'tailwindcss' (or vite, laravel-vite-plugin) during the build

First check whether dependencies were installed without devDependencies (npm ci --omit=dev, npm install --production or NODE_ENV=production). The build tools live in devDependencies and must be installed. If that's not it, do a clean install:

rm -rf node_modules
npm ci

Don't delete package-lock.json. npm ci installs exactly from that file; deleting it means the server may end up with different package versions than your machine.

Error 3: The build succeeds but the site is still broken

• Still getting Vite manifest not found: compare the path in the error with where the build is (see "Diagnose first"). It's almost always a mismatch in the public path or build directory.
• The page has no CSS or JS and requests go to localhost:5173 or [::1]:5173: a public/hot file is left behind; delete it.
• You're on Octane: workers still hold the old manifest in memory; run php artisan octane:reload.
• JS and CSS files return 404: the page HTML comes from a cache (full-page cache or CDN) and points to hashes from a build you deleted. Purge the cache and keep the previous build around for a while (like build-old in the workflow above).

Error 4: Files load but the browser won't apply the CSS or run the JS

Check the Console and Network tabs in DevTools:

• Mixed Content error: the site is on HTTPS but the asset URLs are http://. Usually Laravel, sitting behind a proxy or CDN, doesn't know the request was HTTPS. That's the same issue covered in the trustProxies section of our guide to fixing Laravel 419 Page Expired. If you serve assets from another domain, also check ASSET_URL.
• MIME type message (for example text/plain): in your Nginx config, the http block should have include /etc/nginx/mime.types;.
• Content Security Policy error: if you use a CSP, add your asset domain or a nonce to it. Laravel adds a nonce to the tags @vite generates when you call Vite::useCspNonce().

FAQ

1. Why does npm run build work locally but not in CI or on the server?

Three common reasons: (a) a different Node version; always set node-version explicitly in GitHub Actions. (b) The VITE_ variables you have in your local .env aren't defined in CI. (c) devDependencies weren't installed (Error 2).

2. Can I commit public/build to git?

You can, but it's not recommended. Build files change with every change, clutter the repository history, and there's always a risk that the committed build doesn't match the code. Laravel also puts /public/build in .gitignore by default. If you're on shared hosting without CI, the manual upload method above is cleaner.

3. How do I build in Docker?

Use a multi-stage Dockerfile:

# Stage 1: build assets
FROM node:24-alpine AS assets
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: production
FROM php:8.4-fpm
WORKDIR /var/www/html
COPY . .
# Copy the build after the code so nothing overwrites it
COPY --from=assets /app/public/build ./public/build

The final image has no Node, and the build is produced from scratch every time. Also list node_modules, public/build and public/hot in .dockerignore. (PHP extensions and composer install are left out of this example.)

4. Is Vite different from Laravel Mix?

Yes. Since Laravel 9.19, new Laravel projects use Vite instead of Mix (which is built on webpack). Mix produced mix-manifest.json and you used mix() in Blade; with Vite you use @vite() and the manifest is written to public/build/manifest.json. If you migrated an old project and still have mix() calls somewhere, replace them too.

5. How do I install Node on the server without nvm?

With NodeSource packages:

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs

Before piping any script from the internet into bash, take a look at what it does.

6. Should I commit package-lock.json?

Yes, always. npm ci won't run without package-lock.json (or when it's out of sync with package.json), and without a lock file every build may pull different package versions.

If I had to sum up this article in one sentence: read the path in the error message, check whether public/build/manifest.json is really there, then pick one consistent way to build (on the VPS, in CI, or on your machine) and make every deploy verify the manifest is in place. Correct, lean assets aren't only about fixing errors; they also affect page speed and Core Web Vitals, which the Vite section of our Laravel technical SEO guide covers.

Deploy still failing? Paste the full error, your npm run build output and vite.config.js into Nyx, Captain Code's AI assistant, and work through where the build gets lost step by step. If you'd rather have the whole pipeline (build, deploy and server upkeep) set up properly once so you can stop thinking about it, that's what website security and maintenance and custom Laravel development are for; just send us your project.

If you're still learning backend and deployment and wondering where all of this fits, read Frontend, Backend, or Full-Stack? and the best programming languages to learn in 2026.

Questions, or stuck somewhere? Ask in the comments.

Why is this question more serious than ever in 2026?

A few things in 2025–2026 changed the equation. First, the Stack Overflow Developer Survey 2025 (published December 29, 2025) showed that 84% of developers now use AI tools, and 51% work with them daily. That means the role of all three branches is shifting toward "reviewer and architect" rather than "line-by-line coder." Second, skilled migration and the rise of remote work pushed Iranian salaries in 2025–2026 up sharply (numbers below). Third, AI coding tools (Cursor, Claude Code) made frontend work faster because visual output is quick to test, while backend work still needs systemic thinking.

What makes this article different: the salary tables cite the official Stack Overflow 2025 report and the Scalify.ai Full-Stack Salary Report 2026, plus real Iranian job-listing ranges from 2025–2026 — not recycled numbers from older posts. At the end you also get hands-on notes from 5+ years of Laravel freelancing and production projects, not textbook theory.

The real difference between these three paths (not the textbook definition)

Before the numbers, it helps to be clear what each path actually looks like day to day. A lot of career-path articles stay shallow or just repeat the same restaurant/shop analogy.

Frontend is anything the user sees in the browser and interacts with — buttons, forms, animations, page layout. The main technologies in 2026 are HTML/CSS, JavaScript, TypeScript, React, Next.js, Vue.js or Svelte, and for styling Tailwind CSS or CSS Modules. A frontend developer works with UX designers and the backend team.

Backend is the behind-the-scenes logic: database, API, authentication, security, payment processing. The main technologies are Node.js, Python (Django/FastAPI), PHP (Laravel), Java (Spring), C# (.NET), Go, Rust, and databases like PostgreSQL, MySQL, and MongoDB. A backend developer works with the database and system architecture.

Full-stack means being competent enough in both. Not necessarily excellent in each, but enough to deliver a small-to-medium project end to end on your own.

The practical difference nobody talks about: frontend gives you instant feedback (you write code, and five seconds later you see it in the browser). Backend is delayed (you write code, then have to test the API, read logs, and check the database). That seemingly small difference is huge for learning speed and daily satisfaction.

2026 salary comparison — real global data

The data below comes from two sources:

• Stack Overflow Developer Survey 2025 (49,000+ developers, 177 countries, published December 29, 2025)
• Scalify.ai Full-Stack Salary Report 2026 (April 2026, U.S. data)

Table 1: Median annual salary (USD) in 2026

Important note: full-stack at the Mid and Senior levels pays about 5–10% more than the specialists in the Scalify breakdown. That premium mainly holds up to Senior. Above that, specialization (for example, backend for distributed systems) tends to earn more.

Table 2: Technology stack distribution in full-stack (2026)

Source: Scalify.ai 2026 Breakdown.

Key findings from the Stack Overflow 2025 data

• 84% of developers use AI tools (76% in 2024)
• 51% of professionals use AI daily
• 46% distrust AI output; only 3% fully trust it
• Cursor (the AI-first editor) captured 18% of the market in its first appearance
• Claude Sonnet is the most-used model among professionals at 42.8% (30% among students)
• PostgreSQL overtook MySQL at 55.6%

These numbers directly influence your path choice: whichever branch you pick, you need to be AI-fluent. 76% of developers do not use AI for deploy or production monitoring — which means if you know how, you have a real competitive edge.

The Iranian market in 2025–2026 — what are the real numbers?

The Iranian market ranges below are based on Jobinja, JobVision, and reports from Hooshka and Sadrhesab in 2025–2026:

Table 3: Monthly developer salary in Iran (2025–2026, toman)

Important note for the Iranian market: Iranian companies now compete with dollar salaries paid to freelancers. Many Iranian developers work remotely with teams in the UAE, Europe, and Canada and earn about $4,000–$6,000 a month. That means salaries above 150 million toman for Seniors are no longer unusual.

Personal experience in the Iranian market: backend Laravel (PHP) has steady but mid-ceiling demand thanks to traditional corporate sites, e-commerce, and booking systems. React and Next.js are growing faster thanks to startups and B2B products. Backend Python (Django/FastAPI) is seeing more demand because of AI, though its share is still smaller.

How many months until your first real income?

This is the question most career articles skip. The table below is an estimate from freelance reports and 2025–2026 market experience in Iran and abroad — not a survey median:

Table 4: Estimated time to first income (serious learning, 3–4 hours/day)

Why is frontend usually faster? Three reasons:

1. You can build a visual portfolio more easily. Put a sample site on GitHub Pages and the client sees the result quickly.
2. Freelance demand is high: corporate sites, landing pages, and small e-commerce shops are mostly frontend-heavy.
3. AI tools like Cursor and Claude Code have made frontend scaffolding faster. Building a React component with AI can take minutes, but debugging a backend API still takes real time.

But here is the warning: reaching income faster ≠ the best long-term path. If your goal is only income within the first six months, frontend wins. If you want salary growth five years from now, backend or full-stack is usually the smarter bet.

The full-stack glass ceiling — why specialization sometimes wins

A common belief says "full-stack is better because you know everything." After 5+ years of freelancing and working with different teams, that belief tends to hold up to Senior, and then stops.

Why? Three practical reasons:

1. Depth vs breadth: full-stack is valuable at the Junior-to-Mid stage because you can deliver small-to-medium projects alone. Once you reach Senior, the market wants depth: "How well do you understand distributed systems?", "What is your experience with Event Sourcing?", "How do you scale a system from 10,000 users to 1 million?" Those questions are backend-specialist territory.

2. Freelance hourly rate: in real projects, a senior backend specialist focused on Python + AI often charges about $80–$120 per hour, while a generalist full-stack developer is closer to $40–$60. That gap comes from deep specialization in a high-paying niche (personal project rates, not a published survey).

3. Career ceiling: Table 1 shows full-stack reaching about $198K at the Staff/Principal level in the Scalify data. Backend specialists in niches like financial systems or AI/ML infrastructure often go higher still — those upper bands are market anecdotes, not a single survey cell.

Exception: if you plan to launch your own startup or serve as a Technical Lead for a small team, full-stack is often the best choice. You need to understand everything and decide quickly.

The dollar path — which branch is better for remote work?

If your goal is international clients and dollar income, look at demand separately. Patterns from platforms like Upwork, Toptal, and A.Team in 2025–2026 (directional, not a single published wage table):

Frontend for remote:

• Strong demand for short-term projects (corporate sites, dashboards, landing pages)
• Mid-Level hourly rate often roughly $35–$70
• Large share of short freelance listings
• Advantage: a visual portfolio is easy to show

Backend for remote:

• Longer projects with higher contract value
• Mid-Level hourly rate often roughly $50–$90
• Higher demand for Python + AI and Go + microservices
• Advantage: more stable income, larger projects

Full-stack for remote:

• Strong fit for early-stage startups that want one generalist
• Hourly rate often roughly $60–$100 (depends on depth)
• Advantage: flexibility and diverse project types

Personal take: on remote platforms, React/Next.js + Node.js + a knack for AI is a strong balance of volume and rate. Going deep into AI/ML (Python + LangChain + vector databases) raises the ceiling further because that niche still has a talent shortage.

If you are still picking a first language for that path, see the best programming languages to learn in 2026.

Summary — when to pick frontend, backend, or full-stack

Pick frontend if:

• You want to reach your first income fast (3–6 months)
• You enjoy seeing the result of your work (instant feedback)
• You care about design and user experience (UX)
• You want to freelance or do remote work with short projects
• You are still unsure which path you want (frontend is a good starting point)

Pick backend if:

• You enjoy deep problem-solving and logic
• You want the highest salary ceiling ($200K+)
• You like working with data, system architecture, and performance
• You want to get into AI/ML (backend Python is essential)
• You are patient and not in a rush for your first income

Pick full-stack if:

• You want to launch a startup or work as an all-rounder freelancer
• You like delivering projects end to end
• You enjoy diverse learning (with less depth in each area)
• You want to become a Technical Lead or CTO
• You prefer working independently rather than in a large team

One last piece of advice: if you are a complete beginner, begin with frontend (React + TypeScript). Three months in, if you are drawn to backend and databases, continue toward full-stack. If you get tired of CSS and design, shift toward backend. Your first choice is never your final choice.

Frequently asked questions (FAQ)

1. Does full-stack still have demand in 2026?

Yes. Full-stack remains one of the most in-demand roles, especially in startups and small-to-medium companies. According to the Scalify.ai 2026 report, full-stack developers at the Mid to Senior level earn about 5–10% more than specialists. At higher levels (Staff+), deep specialization is usually worth more.

2. Which path is best for career migration?

It depends on the destination. For Canada and Australia, backend (especially Java/.NET) is often in high demand. For Germany, frontend and full-stack are more common. For international remote work, full-stack with React/Next.js + Node.js, or backend Python, is a strong option.

3. Will AI replace programmers?

According to the Stack Overflow Survey 2025, 84% of developers now use AI, but only 3% fully trust AI output. 76% do not use AI for deploy. AI replaces a lot of repetitive coding, not thinking and architecture. AI-fluent developers have the biggest advantage.

4. Which language is best to start with in 2026?

For frontend: TypeScript (not only vanilla JavaScript). For backend: Python (if you also want AI) or Node.js (if you are coming from frontend). For full-stack: React + Next.js + Node.js + TypeScript has the highest market demand among the stacks in Table 2.

5. Do I need a computer-science degree?

No. Most 2026 job listings ask for practical skill and a portfolio, not a university degree. According to the Stack Overflow Survey 2025, about 35% of professional developers do not have a formal computer-science degree. For immigration paperwork and some Senior roles, a degree can still help.

6. How long until I reach Mid-Level?

With serious learning (3–4 hours/day): roughly frontend 8–12 months, backend 12–18 months, full-stack 15–24 months if you start from zero. With prior programming experience, expect to move 30–50% faster. These are experience-based ranges, not survey medians.

Sources:

• Stack Overflow Developer Survey 2025 (49,000+ responses, 177 countries, published December 29, 2025)
• Scalify.ai Full-Stack Developer Salary 2026 Breakdown (April 2026)
• Iran developer salary ranges 2025–2026 (Jobinja, JobVision, Hooshka, Sadrhesab)
• Author experience from 5+ years of Laravel freelancing and production projects

Still deciding between frontend, backend, and full-stack — or building a product that needs all three? Try Nyx, Captain Code's AI coding assistant when you want a second pair of eyes on architecture or code. If you would rather hand the build off, from custom web development to security and maintenance, you can talk to Captain Code.

More on languages and market demand: Best programming languages to learn in 2026.

Originally published on Captain Code.

Why is this question suddenly important now?

If you are looking to learn programming in 2026, you are facing a real fork in the road. On one side, the Stack Overflow 2024 and GitHub Octoverse 2024 reports show that Python and JavaScript are still the most widely used languages. On the other side, the TIOBE Index for July 2026 officially announced that Rust has joined the world's top ten languages. The map is shifting.

What makes this article different from the rest comes down to two things. First, every piece of data is sourced from authoritative 2024–2026 reports, not copied from older articles. Second, you will get practical experience working with these languages, not just definitions and praise. If you are just starting out, there is also a practical roadmap at the end of the article.

Real Criteria for Choosing a Language, Not Just "the Most Popular"

No language is absolutely "the best." Choosing a language depends on four factors you should know before you start:

1. Career goal — Do you want to do backend web work, build mobile apps, write operating systems, or move into AI? Each domain has its own language.
2. Learning speed — Python and JavaScript are picked up faster because of their simple syntax. Rust and C++ have steeper learning curves but higher salaries in return.
3. The Iranian job market — Job listings on Jobinja and JobVision in 2025–2026 show that JavaScript, Python, and PHP have the highest demand, but for international remote work Python and Rust pay more in USD.
4. Ecosystem and future — The language you learn needs to still be in demand five years from now. Python and JavaScript have that guarantee; Rust is in the middle of proving itself.

Python: The Undisputed King of AI and Data

Python in 2026 remains the first choice for artificial intelligence, machine learning, data science, and automation. According to GitHub Octoverse 2024, Python overtook JavaScript and became the most popular language on GitHub — a shock to the developer community, because JavaScript had held the top spot for years.

Why has Python grown so much? The main reason is the explosion of AI tools. Libraries like TensorFlow, PyTorch, Hugging Face Transformers, and LangChain were either first written for Python or offer their best support there. Any company that wants to build an AI product today looks for Python specialists first.

Personal experience: on one of my freelance projects I had to build an automated resume-analysis system with AI. Using Django and the spaCy library I delivered the first version in three weeks. That project showed just how unbeatable Python's ecosystem is for startups and MVPs. Development speed is high, debugging is simple, and the support community is huge.

Current version: Python 3.13 (October 2024), which brings significant runtime-performance improvements.

JavaScript and TypeScript: The Backbone of the Modern Web

JavaScript is the only language that runs in every browser, on the server (via Node.js), inside mobile apps (via React Native), and even on the desktop (via Electron). According to the Stack Overflow Survey 2024, JavaScript is still the most popular language among professional developers. That said, IEEE Spectrum's September 2025 ranking showed JavaScript slipping from third to sixth — but that is not because of declining popularity; it is because the rise of AI Coding has reduced the volume of hand-written code.

TypeScript has become the default choice for new projects in 2026. If you already know JavaScript, picking up TypeScript only takes two weeks and pays for itself many times over. Almost every backend job listing in Iran in 2025–2026 asks for "JavaScript/TypeScript plus a framework."

The JavaScript framework ecosystem in 2026 includes React 19, Next.js 15, Vue 3.5, Svelte 5, and Angular 19. On the backend side, Nest.js and FastAPI (which is actually Python but is often called from JavaScript) have also become popular.

A note about Iran: if you want to enter the job market quickly, the Laravel + Vue.js + MySQL stack is still the most in-demand combo. But if your goal is international remote work, React + TypeScript + Node.js is the better answer.

Rust: The Serious Newcomer to the TIOBE Top 10 — Why 2026 Is Rust's Year

Rust officially entered the TIOBE top ten in July 2026. That is a historic milestone, because TIOBE has been published since 2001 and until now only C, C++, Java, C#, Python, and JavaScript had held that position. Rust is the first new systems language to reach this rank in twenty years.

Why has Rust become so important? Three reasons:

• Memory safety without runtime overhead — unlike C and C++, Rust prevents common memory errors like use-after-free at compile time.
• Speed close to C — perfect for systems where every millisecond matters (financial services, game engines, blockchain).
• Big-company backing — Microsoft, Google, Amazon, and Meta are all migrating important projects to Rust. The Linux kernel has also been adding Rust code since 2022.

Hands-on experience: the first time I wrote Rust code I ran into the "cannot borrow as mutable because it is also borrowed as immutable" error. For most beginners that is a nightmare. Rust's ownership and borrowing system is hard, but once you learn it you cannot go back to C++.

My advice: if you already work with JavaScript or Python, do not jump straight into Rust. Start with a simpler language first, and once your fundamentals are solid, learn Rust as a second language. But if you are a computer-science student or a systems developer, Rust is the best long-term investment right now.

Final Comparison Table: Top 8 Languages in 2026

This table is built from TIOBE, the Stack Overflow Survey 2024, GitHub Octoverse 2024, and Iranian job listings (2025–2026):

If you are still unsure which one to pick, look closely at the table above. The Iranian salary and job-market numbers are estimated from real Jobinja and JobVision listings in summer 2025–2026, not made up.

Other Languages Worth Learning

Beyond the three headliners, a few more languages are worth learning depending on your specific need:

• C++ — if you want to do game development with Unreal Engine or professional systems programming, it is still unrivaled.
• Go (Golang) — Google's language for scalable backend services. In Iran there is real demand, especially in fintech practical setups.
• Java — if your goal is working in Iranian banks, insurance companies, or telecom operators, Java is still the enterprise default.
• Kotlin — if you only want to build Android apps, Kotlin has become the modern replacement for Java.
• Swift — for iOS and macOS development. In Iran, however, Apple's sanctions make the job market limited.
• C# — especially with Unity in game development and .NET 8 in enterprise apps. Iran also has a healthy market for it.

Will AI Coding Replace Language Choice?

A question I hear a lot lately: "With GitHub Copilot and ChatGPT around, does learning a language even matter anymore?" Short answer: yes, but the kind of learning changes.

AI Coding tools (especially Vibe Coding, which combines natural-language code generation with output review) have automated repetitive work like writing boilerplate, repeating patterns, and even simple debugging. IEEE Spectrum's September 2025 report touched on exactly this: "JavaScript fell from third to sixth in the Spectrum ranking, perhaps because AI is generating more of that code."

But there are three things AI cannot replace yet:

1. Deep system understanding — when a project gets complex and you have to make architectural decisions, AI helps but the decision is yours.
2. Debugging real production issues — AI is good at common errors but usually misleading on complex production bugs.
3. API design and user experience — these need a human understanding.

So learning a language is still essential, but how you learn it has to change. Instead of memorizing syntax, focus on understanding concepts (algorithms, system design, architecture) and problem-solving ability.

Practical Roadmap: Where Are You Right Now, and Which Language Fits?

This roadmap is built from real questions I asked users on freelance projects:

• If you are an absolute beginner and want to enter the job market quickly: start with Python. In three months you can learn Django or FastAPI and start freelancing. Add JavaScript/TypeScript after six months.
• If you want to build websites and web apps: JavaScript + TypeScript + React. The React + Next.js + TypeScript combo is currently the most in-demand freelance stack in Iran.
• If you are a computer-science student or love systems programming: learn C++ properly, then Rust. That combo has an outstanding international job market.
• If you want to get into AI: Python + statistics + machine learning. 2026 is the best time to enter AI with Python.
• If you only want mobile apps: Kotlin for Android, Swift for iOS, or React Native/Flutter for both.
• If you want to start international remote freelancing: Python + Django/FastAPI or Rust + Actix. This combo delivers the highest USD income.

Frequently Asked Questions

Is it too late to learn programming in 2026?

No, it is not too late at all. Global developer demand is projected to grow by more than 25% by 2030, and companies are already facing a shortage of specialists. It does not matter how old you are or what you studied — if you can actually code and solve problems, your career is secure.

Which language pays the most in 2026?

According to the Stack Overflow Survey 2024, Rust, Go, and Python deliver the highest USD salaries in the international market. In Iran, TypeScript and React usually pay the highest freelance rates. But salary depends on skill and domain, not just language.

What is the best language for AI?

Definitely Python. All the major AI frameworks (TensorFlow, PyTorch, Hugging Face) were written for Python. If you want to get into AI, Python is both the first and last choice. Julia and C++ are used in specific cases (heavy computation) but you do not need to learn them to start.

Is Rust hard to learn? Is it worth it?

Rust has a steep learning curve, especially around ownership and borrowing. Most developers need three to six months to feel comfortable. But it pays off: higher salaries, more international opportunities, and access to safety-critical projects. If you are patient and your goal is systems programming, Rust is the best long-term investment.

Should I learn TypeScript separately?

If you already know JavaScript, TypeScript is essential, not optional. Almost every backend job listing in 2026 mentions TypeScript. Learning it after JavaScript only takes two weeks and dramatically improves the quality of your code.

Will AI replace programmers?

Not in the short term. AI is a powerful tool but does not replace human understanding, complex problem-solving, or architectural decisions. But developers who use AI as a tool will replace those who do not. So instead of fearing AI, learn how to work with it.

If it is 2026 and you are just starting, the best thing you can do is pick one of the languages above and start without delay. The "right time" never arrives. The best language is the one you actually start with and build a real project on.

Originally published on Captain Code.

Who this guide is for

You're in the right place if:

• you work with Laravel 10+ and know Blade and @csrf,

• your form or Livewire component works locally,

• but on the real server you see 419 Page Expired or Livewire's "This page has expired" dialog.

If you get 419 locally too, start with the "Simple branch". If it only happens in production, jump to the "Production branch".

How is the CSRF token tied to the session?

According to the official Laravel CSRF documentation:

Laravel automatically generates a CSRF "token" for each active user session managed by the application. This token is used to verify that the authenticated user is the person actually making the requests to the application. Since this token is stored in the user's session and changes each time the session is regenerated, a malicious application is unable to access it.

So the token is bound to the session, and the session is bound to a cookie. A typical production request path:

Browser
   │  Cookie: laravel_session=... + XSRF-TOKEN=...
   ↓
CDN / Cloudflare (optional)
   ↓
Nginx (TLS termination or reverse proxy)
   ↓
PHP-FPM → web middleware group
   ↓
StartSession → session loaded from the cookie
   ↓
ValidateCsrfToken (Laravel 11/12) / PreventRequestForgery (Laravel 13)
   ↓
Request token vs. session token → OK or 419

Anywhere along this path, if the session cookie doesn't reach the app, the session changes, or the page HTML carries another session's token, you get 419.

Simple branch: @csrf and AJAX (usually local)

Scenario A: @csrf is missing from the form

{{-- ❌ Wrong: 419 --}}
<form method="POST" action="/profile">
    <input type="text" name="name">
    <button type="submit">Submit</button>
</form>

{{-- ✅ Correct --}}
<form method="POST" action="/profile">
    @csrf
    <input type="text" name="name">
    <button type="submit">Submit</button>
</form>

@csrf simply renders this hidden field:

<input type="hidden" name="_token" value="{{ csrf_token() }}">

Scenario B: a fetch request without a token

// ❌ Wrong: 419
fetch('/profile/settings', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name: 'ali' })
});

// ✅ Correct: token from the meta tag
fetch('/profile/settings', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-CSRF-TOKEN': document.querySelector('meta[name="csrf-token"]').content
    },
    body: JSON.stringify({ name: 'ali' })
});

To make the token available to JavaScript, add this meta tag to <head>. @csrf only works inside a form, so it isn't enough for AJAX:

<head>
    <meta name="csrf-token" content="{{ csrf_token() }}">
</head>

Note: routes in routes/api.php don't use the web middleware group (and therefore CSRF) by default. 419 comes from routes in the web group.

Scenario C: Axios

Per the Laravel docs, Axios reads the XSRF-TOKEN cookie on same-origin requests and sends it as the X-XSRF-TOKEN header automatically, so usually there's nothing to do. For cross-origin requests (e.g. a frontend on another subdomain), you also need to send cookies:

// resources/js/bootstrap.js
axios.defaults.withCredentials = true;
axios.defaults.withXSRFToken = true; // Axios 1.6+, for cross-origin

Production branch: APP_URL, HTTPS and proxies

APP_URL must match the real site URL

# ❌ Wrong: the site runs on https but APP_URL says http
APP_URL=http://example.com

# ✅ Correct
APP_URL=https://example.com

APP_URL doesn't build the session cookie directly, but Laravel uses it to generate URLs (from the CLI, queued jobs and some packages), and a mismatch with the real URL is the first clue in many http/https problems. After changing .env, run php artisan config:cache again, or the old value keeps being read from the config cache. If your deploys are automated, make sure that step runs after .env is written.

Laravel must know the request was HTTPS (trustProxies)

HTTPS often terminates at a CDN or Nginx, and the request reaches the app over plain HTTP:

Browser (HTTPS) → CDN or Nginx (HTTPS) → Laravel app (HTTP)

If Laravel doesn't trust the proxy, it thinks the request was HTTP. As a result, url(), route() and asset() generate http:// URLs, so your form action or the Livewire update endpoint becomes http://. If SESSION_SECURE_COOKIE=true, the browser won't send the Secure cookie on that http:// request, a fresh session is created, and you get 419. And if the server redirects http to https, the POST body is lost in the redirect.

If Nginx sits in front of another server or container, forward the headers:

location / {
    proxy_pass http://laravel_backend;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;  # ← the key line
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

And in Laravel 11+ (bootstrap/app.php):

->withMiddleware(function (Middleware $middleware) {
    $middleware->trustProxies(at: '*'); // or only your proxy IPs/ranges
})

⚠️ at: '*' is only safe if PHP isn't reachable directly from the internet; otherwise anyone can spoof X-Forwarded-Proto. List your proxy IPs or ranges when you can.

On Laravel 13 there's one more reason this matters: per the Laravel 13 docs, the Sec-Fetch-Site origin check only runs on secure connections. If Laravel sees the request as HTTP, that layer is skipped and everything falls back to the token check.

Cloudflare in Flexible SSL mode

In Flexible mode, Cloudflare talks HTTPS to the browser but plain HTTP to your server:

Browser (HTTPS) → Cloudflare (HTTPS) → Origin (HTTP)

That's the same scenario as above with one extra layer. The fix: switch SSL mode to Full (strict) with a certificate on the origin, and configure trustProxies correctly.

A common case: the site goes behind a CDN or proxy (Cloudflare, for example) and suddenly every Livewire form starts returning 419, even though no code changed. The cause is almost always that trustProxies isn't configured, so Laravel sees the request as HTTP, and combined with SESSION_SECURE_COOKIE=true the session cookie never arrives. That's why these two settings are the first things to check after any CDN or proxy change.

Production branch: the session cookie (Domain, Secure, SameSite)

SESSION_DOMAIN and subdomains

# Default: the cookie is host-only (just the host that served the page)
SESSION_DOMAIN=null

# If the session must be shared between app.example.com and admin.example.com
SESSION_DOMAIN=.example.com

A point that's often explained wrong: once you set a cookie Domain, whether example.com or .example.com, modern browsers send the cookie to all subdomains (the leading dot is ignored). Only an empty (null) SESSION_DOMAIN gives you a host-only cookie. So:

• If SESSION_DOMAIN doesn't match the real site domain (e.g. a staging value left in production), the browser rejects the cookie and every request starts a new session → 419.

• If an old host-only session cookie and a new domain cookie with the same name both exist, the browser may send both and Laravel may read the wrong one. After changing SESSION_DOMAIN, also rename the cookie (SESSION_COOKIE) or clear cookies.

Per the Laravel session documentation, all session cookie settings live in config/session.php and are read from .env.

SESSION_SECURE_COOKIE and SESSION_SAME_SITE

The right combination for an HTTPS-only site:

SESSION_SECURE_COOKIE=true
SESSION_SAME_SITE=lax
SESSION_HTTP_ONLY=true

Two cases that lead to 419:

• SESSION_SECURE_COOKIE=true on a site still served over HTTP (e.g. staging without SSL): the browser won't store a Secure cookie over HTTP, so every form returns 419.

• SESSION_SAME_SITE=none without Secure: modern browsers reject the cookie.

SESSION_SECURE_COOKIE=false on HTTPS usually doesn't cause 419 by itself, but it's a security weakness. As StackShield's guide to Laravel session security explains, the Secure flag makes the browser send the cookie only over HTTPS, so it can't be sniffed on shared networks.

Per the same source, SameSite has three values:

SESSION_HTTP_ONLY defaults to true. Leave it, or JavaScript (and any XSS) can read the session cookie.

Production branch: session driver, multiple servers and page caching

Sessions across multiple servers or containers

In Livewire discussion #4799, one user reported 419 errors on Kubernetes with two pods and SESSION_DRIVER=file: the session was stored on one pod's disk, and the next request hit the other pod. The same applies to multiple PHP containers behind a load balancer. The fix: a shared driver such as redis or database.

On a single server with the file driver, make sure storage/framework/sessions is writable by the PHP-FPM user.

Full-page caching or a CDN

This one is rarely mentioned: if you added full-page caching for speed, or your CDN caches HTML pages, users receive HTML containing another session's csrf_token(). When they submit the form: 419. Exclude pages with forms or Livewire components from full-page caching, or refresh the token with a separate request after load.

Session lifetime

If a user leaves the page open and submits much later, the session may have expired. Laravel's default SESSION_LIFETIME is 120 minutes. For this case, create a friendly resources/views/errors/419.blade.php that tells the user to refresh.

Diagnosis table: 8 scenarios and how to check them

Livewire: why does it return 419?

Livewire sends the token itself: the script that @livewireScripts (or automatic injection in Livewire 3) adds to the page carries the current csrf_token(), and every wire:click and wire:submit request uses it. So you don't need @csrf for Livewire actions. If you get 419, it's almost always one of the session problems above. When a 419 comes back, Livewire shows its "This page has expired" dialog and offers a refresh.

Other fixes that worked in discussion #4799:

• After updating Livewire, if you published its assets, publish them again (php artisan livewire:publish --assets); old JS doesn't match the new backend.

• Check SESSION_DOMAIN to confirm the session cookie actually gets stored.

• If you define Livewire routes in a package, make sure they have the web middleware group.

Some people in that discussion suggest excluding livewire/* from CSRF. Don't. It hides the real problem and leaves every Livewire action unprotected.

Laravel 13: origin-aware CSRF protection

Per the Laravel 13 docs, the middleware is now PreventRequestForgery with two layers: it first checks the Sec-Fetch-Site header and allows same-origin requests without a token check; if that check isn't possible (older browser, or an insecure connection), it falls back to normal token validation.

If you're on Laravel 13 and getting 419:

1. Check the request's Sec-Fetch-Site value in the Network tab. If it's cross-site or same-site, the request comes from another origin (subdomain, iframe) and needs a token.

2. For subdomains, consider preventRequestForgery(allowSameSite: true).

3. If Laravel sees the request as HTTP (see trustProxies), the origin layer never runs.

Note: in originOnly: true mode, rejected requests get 403 instead of 419.

Why you should never disable CSRF

Never do this:

// ❌ Never
->withMiddleware(function (Middleware $middleware) {
    $middleware->validateCsrfTokens(except: ['*']);
})

It lets another site submit forms on behalf of your logged-in users (changing their email, deleting their account, and so on).

The right exception: webhooks

Only for third-party webhooks that can't send a token (Laravel 11 and 12; on Laravel 13 the method is preventRequestForgery):

->withMiddleware(function (Middleware $middleware): void {
    $middleware->validateCsrfTokens(except: [
        'stripe/*',
        'webhooks/*',
    ]);
})

Per the Laravel documentation:

Sometimes you may wish to exclude a set of URIs from CSRF protection. For example, if you are using Stripe to process payments and are utilizing their webhook system, you will need to exclude your Stripe webhook handler route from CSRF protection since Stripe will not know what CSRF token to send to your routes.

⚠️ Even after excluding a webhook, always verify its signature (e.g. the Stripe-Signature header).

FAQ

1. What's the difference between ValidateCsrfToken and PreventRequestForgery?

ValidateCsrfToken is the middleware name in Laravel 11 and 12, and it only checks the token. In Laravel 13 it's renamed PreventRequestForgery and checks the Sec-Fetch-Site header before the token.

2. Why does it work locally but not in production?

Locally you usually have one domain, plain HTTP and one server. Production adds HTTPS, a proxy or CDN, subdomains, multiple servers and caching. The most common causes: trustProxies not configured, wrong SESSION_DOMAIN or SESSION_SECURE_COOKIE, a non-shared session driver, and cached HTML.

3. Can I disable CSRF for just one route?

Yes, with validateCsrfTokens(except: [...]) (or preventRequestForgery(except: [...]) on Laravel 13). But only for webhooks and third-party endpoints, never for user-facing routes.

4. Where do I see cookies in DevTools?

Chrome: F12 → Application → Storage → Cookies. Firefox: F12 → Storage → Cookies. Safari: Develop → Show Web Inspector → Storage → Cookies.

5. Livewire 3 returns 419 in production. Where do I start?

1. View Source and check that the Livewire endpoint URL is https:// (trustProxies).

2. In DevTools, check that the session cookie gets stored (SESSION_DOMAIN, SESSION_SECURE_COOKIE).

3. With multiple servers, use a shared session driver.

4. Make sure the page isn't served from a full-page cache or CDN.

6. Why does Livewire sometimes return 419 even with a valid token?

Because the token is valid, but for a different session: the session expired, the request reached a server that doesn't have the session, or the HTML came from a cache. Check those three first.

If you go through the two branches separately and work down the diagnosis table, it usually becomes clear quickly where the session gets lost. And remember: the fix for 419 is never disabling CSRF. It's one of your application's core defenses.

Still stuck on 419, or don't have time to debug it? Give the error, your .env (without keys and passwords) and your Nginx config to Nyx, Captain Code's AI coding assistant, and debug it step by step. Or if you'd rather hand the whole thing off, from custom Laravel web development to security and maintenance, you can bring your project to Captain Code.

New to backend work? See the best programming languages to learn in 2026.

Good luck. If you have a question or get stuck, ask in the comments below.

Originally published on Captain Code.