Get help on Discord

Different login URLs for development and production in Sanity Studio

3 replies
Last updated: Dec 1, 2025
Hi! I'm trying to specify a custom login URL to my sanity studio in the 
config/@sanity/default-login.json
file, but I'm not sure how I can specify one for development and another for production. My setup looks like this:

{
  "providers": {
    "mode": "replace",
    "redirectOnSingle": true,
    "entries": [
      {
        "name": "custom-login",
        "title": "Custom login",
        "url": "<http://localhost:3000/api/auth/login>",
        "logo": "static/custom-logo.svg"
      }
    ]
  }
}
How do I replace 
<http://localhost:3000>
with 
<https://production.app.com>
when deploying to production?
AI Update

The config/@sanity/default-login.json file is a static JSON file that doesn't support environment variables directly. However, there are a couple of approaches you can use to handle different URLs for development and production:

The simplest approach is to maintain separate JSON files and copy the appropriate one during your build/deployment process:

config/@sanity/default-login.development.json:

{
  "providers": {
    "mode": "replace",
    "redirectOnSingle": true,
    "entries": [
      {
        "name": "custom-login",
        "title": "Custom login",
        "url": "http://localhost:3000/api/auth/login",
        "logo": "static/custom-logo.svg"
      }
    ]
  }
}

config/@sanity/default-login.production.json:

{
  "providers": {
    "mode": "replace",
    "redirectOnSingle": true,
    "entries": [
      {
        "name": "custom-login",
        "title": "Custom login",
        "url": "https://production.app.com/api/auth/login",
        "logo": "static/custom-logo.svg"
      }
    ]
  }
}

Then add a build script to your package.json:

{
  "scripts": {
    "dev": "cp config/@sanity/default-login.development.json config/@sanity/default-login.json && sanity dev",
    "build": "cp config/@sanity/default-login.production.json config/@sanity/default-login.json && sanity build",
    "deploy": "cp config/@sanity/default-login.production.json config/@sanity/default-login.json && sanity deploy"
  }
}

Solution 2: Generate the File Dynamically

Create a Node.js script that generates the configuration file based on environment variables:

scripts/generate-login-config.js:

const fs = require('fs')
const path = require('path')

const isProduction = process.env.NODE_ENV === 'production'
const loginUrl = isProduction 
  ? 'https://production.app.com/api/auth/login'
  : 'http://localhost:3000/api/auth/login'

const config = {
  providers: {
    mode: 'replace',
    redirectOnSingle: true,
    entries: [
      {
        name: 'custom-login',
        title: 'Custom login',
        url: loginUrl,
        logo: 'static/custom-logo.svg'
      }
    ]
  }
}

const configPath = path.join(__dirname, '../config/@sanity/default-login.json')
fs.writeFileSync(configPath, JSON.stringify(config, null, 2))

Update your package.json:

{
  "scripts": {
    "dev": "node scripts/generate-login-config.js && sanity dev",
    "build": "NODE_ENV=production node scripts/generate-login-config.js && sanity build",
    "deploy": "NODE_ENV=production node scripts/generate-login-config.js && sanity deploy"
  }
}

Important Notes

  1. This feature is deprecated: The third-party login documentation indicates this is a legacy method. For new implementations, consider using SAML SSO instead, which is the modern and recommended approach.

  2. Enterprise feature: Custom authentication is only available on certain Enterprise plans.

  3. Don't commit the generated file: Add config/@sanity/default-login.json to your .gitignore to avoid committing environment-specific URLs to your repository.

The first solution is generally simpler and more reliable since it doesn't require additional dependencies or scripts to run before every command.

Show original thread
3 replies

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?