Configuring Google Maps API key in a Sanity.io project hosted on Netlify

15 replies
Last updated: Jul 27, 2021
I imagine this is config 101 stuff, but I can’t seem to figure it out.
I’m trying to use the Google Maps input, and I don’t want to include my API key directly into google-maps-input.json. I’m hosting on Netlify, and I know where to set up my API key in as a site env variable. But I can’t quite figure out the right syntax to get that env variable into my json file. (For that matter, I’m not quite sure how to do it on my dev json file, either.)
AI Update

Good news - you're actually dealing with a common migration scenario! The google-maps-input.json file was the old Sanity Studio v2 way of configuring the Google Maps plugin, but in Studio v3, you configure plugins directly in your sanity.config.ts (or .js) file where you can use environment variables.

Here's how to set it up properly:

In Studio v3 (Current Version)

In your sanity.config.ts or sanity.config.js file:

import {defineConfig} from 'sanity'
import {googleMapsInput} from '@sanity/google-maps-input'

export default defineConfig({
  // ... your other config
  plugins: [
    googleMapsInput({
      apiKey: process.env.SANITY_STUDIO_GOOGLE_MAPS_API_KEY
    })
  ]
})

Then create a .env.development file in your Studio folder:

SANITY_STUDIO_GOOGLE_MAPS_API_KEY=your-api-key-here

The key thing: all environment variables accessible in Studio must be prefixed with SANITY_STUDIO_. This is how Sanity knows to make them available in the browser-based Studio, as explained in the environment variables documentation.

For Netlify Deployment

In your Netlify site settings:

  1. Go to Site settings → Environment variables
  2. Add SANITY_STUDIO_GOOGLE_MAPS_API_KEY with your API key value
  3. Make sure it's set for the production context

When Netlify builds your Studio, it will automatically inject these environment variables.

Why JSON Files Don't Work

JSON files can't use environment variables because they're static data files, not executable code. This is why the old google-maps-input.json approach was limiting. The v3 configuration approach using sanity.config.ts/js is much more flexible because it's actual JavaScript that runs at build time and can access process.env.

Security Note

As mentioned in the environment variables documentation, anything prefixed with SANITY_STUDIO_ will be exposed in your built Studio bundle (since it runs in the browser). For Google Maps API keys, this is expected - just make sure to restrict the key in Google Cloud Console to only allow requests from your Studio domains.

You can find more details about configuring the plugin on the official Google Maps input plugin page.

are you hosting the front end app on Netlify, and the studio on Sanity.io , or are you hosting the studio on Netlify also?
Good question. I started from the Sanity-11ty blog starter, and I think that set the studio up at Netlify as well.
You'd have to take some extra steps to host the studio anywhere but Sanity. What happens when you run
sanity deploy
?
Assuming you are hosting the studio on Sanity, when you run
sanity deploy
it will send your env vars up to Sanity with your code as long as you prefix them with
SANITY_STUDIO
. So, for example, in my
.env.production
I have:
SANITY_STUDIO_WHATEVER="123"
Then, in my studio code, I have something like
process.env.SANITY_STUDIO_WHATEVER
Oh, I hadn’t done
sanity deploy
I don’t think that was part of the config instructions with the starter. I’ll try that instead! Thanks.
Okay, I’m back. I’ve set up a sanity.studio for this project and deployed successfully. I’ve included my API key in an
.env.production
, and it appears to include the key as part of the JavaScript bundle on deploy.
But now I’m kind of stuck back at my original question: What’s the syntax for including that key in
google-maps-input.json
?
I’ve tried this, but the key doesn’t appear to be applied, and the map fails to load properly:


{
  "apiKey": "process.env.SANITY_STUDIO_MAP_KEY",
}
(I assume that the key in this instance is literally
process.env.SANITY_STUDIO_MAP_KEY
.)
And I tried this, but the deploy fails with an `Unexpected token p in JSON at position 14`:


{
  "apiKey": process.env.SANITY_STUDIO_MAP_KEY,
}
Is my question clearer now?
Yeah, the API call in the first instance is
<https://maps.googleapis.com/maps/api/js?key=process.env.SANITY_STUDIO_MAP_KEY&librarie[…]ces&callback=___sanity_googleMapsApiCallback&language=en-US>
Ah, I see. The issue I think is that
json
doesn't "run" - you can't interpolate values in it.
I am guessing that you would be able to restrict the use of your key so that only requests made from a particular origin are fulfilled: https://developers.google.com/maps/documentation/javascript/get-api-key ?
Thanks. I guess I didn’t know if the plugin would be able to read the token somehow if I got it in the
json
the right way.
I’ve limited the key to the studio origin and I’ve added it to the
json
. That works, and I guess you’re right that there shouldn’t be a security issue with having that token in the repo (especially since it’s a private repo for now).
Thanks for your time. Have a nice day!
I am guessing if the key is only visible to someone making a request from the studio, and your repo for your studio is private, then you should be ok? But, I do tend to scratch my head and look for the official best way*™* of doing this kind of thing
Right? Knowing the difference between “I must not be doing this the right way” and “I shouldn’t be doing this at all” is tricky, especially when you’re learning. Anyways, thanks again.
Totally - I'm in the same boat, learning as I go. I'm guessing you already Googled your way to this, but this looks helpful: https://cloud.google.com/blog/products/maps-platform/google-maps-platform-best-practices-restricting-api-keys
I’m not sure I’ve read that one, so I’ll check it out. Thanks!

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.

Was this answer helpful?