#Environment Variables outside of .env.local?

32 messages · Page 1 of 1 (latest)

undone orbit
#

We are building a single frontend next app that will be hosted on multiple domains and need to reflect the different branding for each domain as set in our CMS (we have an object that describes the branding settings)

Each domain will be a separate deployment. I was trying to figure out a way to have next understand which domain it is building and to tell he backend during build time so that the proper branding info is used. I thought env variables would be the way, but we dont want this stored in our repo, so env vars like vercel env vars would prob work. but how do i recreate that locally?

sorry if this is explanation soup.

old coral
#

@undone orbit

How are you deploying the Next.js application?

undone orbit
#

i havent gotten that far yet 🙂 im pretty new to this. suggestions that would make what im describing possible?

old coral
#

I mean, are you, say, planning to use Docker, Vercel, etc?

Because the methods for handling environment variables will vary based on the deployment method

undone orbit
#

I would say very likely vercel

#

Which I have read through their env docs. how do i replicate those envs locally but outside of my repo?

old coral
#

I would say this is what you are looking for:

#

Have you added the variables in there?

undone orbit
#

No not yet, this is all in planning stage at this point. I saw that as an option. however none of the documentation spoke about how to create env vars like that locally

#

I think i need to look more into the vercel dev/deploy process, my answer is in there

#

thank you for pointing me in the right direction

old coral
#

For development you can just use a .env file, and add the variables inside Vercel when you want to go live, you can also separate the variables based on the environment, however, to be honest, I am not sure if using a .env file is the best solution for achieving what you want.

Have you considered a layout component and checking router.pathname from useRouter (in next/router)?

undone orbit
#

how do i get the domain during build time?

#

that was what i was trying to solve with the env. so id deploy to 2+ diff vercel projects. each with thier own env variable values to tell the app to get whatever domain's branding stuff

old coral
#

Are you using SSR or is everything client-side?

undone orbit
#

i am hoping its largely ssr/ssg

#

its ecommerce where the backend is one thing. and multiple different branded storefronts

old coral
#

Just a wild guess, as I haven't tested the code myself, but try something like this:

import { useRouter } from 'next/router';

const router = useRouter();
const origin = typeof window !== 'undefined' && window.location.origin ? window.location.origin : '';

const address_url = origin+router.asPath;    
undone orbit
old coral
#

Then do a check for the origin

undone orbit
#

i dont think i have access to the window during the ssg right?

old coral
#

That is why you check typeof window !== 'undefined'

undone orbit
#

right i understand in the client side how to do this. because all those things like origin are available

#

but pretty much all landing and product pages id like rendered statically

#

again, im very new to this. so i may be approaching this with the wrong perspective

#

after you earlier comments, ive looked a tiny bit more into using vercel. and locally i can set envs. so i can have 2 vercel projects

#

using the same git repo. and the same api

#

and different envs which would pull the branding out of the api appropriately for each project

old coral
#

yes, I am just not sure if the way you mentioned is the optimal one in the long run, which was why I suggested checking for the domain/url inside of the actual code

#

there's usually more than one way to solve an issue, you just have to choose the one you are the most comfortable with, and which will save you work in the long run

undone orbit
#

true, i will contemplate the things you have suggested, thank you for helping me expand my thoughts a bit here