Can't use environment variables set in netlify.toml

I’m trying to use different environment variables depending on the deployment context. The idea is to use a branch, “qa”, to do pre-deployment testing and then use “main” for production. I’m working with next.js.

My netlify.toml looks like this:

[build]
  command = "next build"
  functions = "netlify/functions"
  publish = "out"

[context.production]

[context.branch-deploy]

[context.qa.environment]
  MY_SPECIAL_VAR = "something goes here"

I then have a basic Next page that uses getServerSide props, where I’m checking that the environment variable is being loaded properly.

import Head from 'next/head';
import Header from '../components/layout/Header';
import styles from '../styles/Home.module.css';

export default function Home({ thing }) {

  return (
    <div className={styles.container}>
      <Head>
        <title>Nextjs | Next-Auth</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <Header />
      <main className={styles.main}>
        <h1 className={styles.title}>
          The thing is {thing}
          Authentication in Next.js app using Next-Auth
        </h1>
      </main>
    </div>
  );
}

export function getServerSideProps(ctx) {
  return {
    props: {
      thing: process.env.MY_SPECIAL_VAR
    }
  };
}

When I do this locally everything works, but when I push to my qa branch and there is an automatic build, MY_SPECIAL_VAR is undefined (or at least doesn’t show up).

Is this because the variable is not available during runtime and only at build time? (I don’t think that’s the case). Or is my .toml syntax wrong? I’ve tried to follow the docs on this but weirdly can’t get it to work.

Additionally, what is the best approach to define the context where the build is happening? I tried to set NODE_ENV but there was a bit of output in the build logs that said this was a bad idea.

It would be great to have some feedback on why this isn’t working, how I can validate my env variables and what the best approach is to set different environment variables for different build contexts. Thanks in advance for your help .

That’s exactly the case. The variables defined in netlify.toml are accessible only during the build time. Add those variables to Netlify UI and you’d be good to go.

Thanks Hrishikesh,

Does that mean I can’t define database urls with environment variables? For example, if I want to use a different DB connection string for QA and one for main, (and assuming that I use the strings as part of a connection in a lambda function), is it the case that those strings will be undefined when the function is called?

I’ll try it myself but would be great to hear your advice. Thank you again.

You can. Simply add those Environment Variables in Netlify UI. Does that work for your use case?

It might be that I couldn’t find it, but in Netlify I could only find variables that are used in all contexts. Would the best thing be simply to have variables like QA_CONNECTION and PROD_CONNECTION?

Thanks again,
R

You can set multiple environment variables, for example, FOO = key1, BAR = key2 and you can access them like:

let apiKey = process.env.CONTEXT === `foo` ? process.env.FOO : process.env.BAR

Basically, you can check for context in your functions and choose the appropriate variable.

@raph37 If @hrishikesh doesn’t mind me slipping a quick setup I would typically recommend is to keep QA in a separate branch and then create a new site that targets that branch with the same exact environment code names, so you aren’t changing your code per QA vs Production. QA devs would then have access to the QA site with no difference in code or setup than the values of the environment vars and maybe a subdomain on that site (qa.example.com)

By all means, this is just a suggestion. I don’t have a full understanding of your requirements/use case.

If you aren’t making changes to QA code prior to release, then the QA site could still point to your production branch if your code is setup to handle that instance.

#TestInProduction :grin:

Thank you both @hrishikesh and @talves .

I think the best solution for me is to do what @talves suggests, and use an entirely different site with the same environment variables. However I really appreciate both of you helping me with this problem.

Many thanks and all the best,

Raph

2 Likes