Usar variables de entorno en Next.js

Las variables de entorno nos permiten configurar como un software se ejecuta dependiendo de la computadora (entorno) donde corre, un uso muy común de estos es definir datos de conexión a una base de datos los cuales van a cambiar si estamos en un entorno de desarrollo (nuestra computadora), uno de testing (CI) o producción.

Next.js tiene integrado soporte para estas variables de varias formas.

Usando .env

Lo primero es crear un archivo .env, en este podemos poner cada variable en su propia lína en un formato KEY=VALUE.

Cuando iniciamos nuestra aplicación de Next con next dev o hacemos build con next build este detecta la existencia del archivo .env y se encarga de que nuestro código pueda acceder a estas variables a través de process.env.

Hay una única regla sin embargo, dado que normalmente las variables de entorno se usan para datos sensibles como contraseñas o tokens de acceso es peligroso que nuestro Frontend pueda, por accidente, exponerlos y debido a que las variables no existen en el navegador la única forma de usarlas es poniendo el valor donde se use, un ejemplo de esto es que este código:

const token = process.env.TOKEN;

Si el TOKEN es igual a abc123 entonces el código de arriba se convierte en el siguiente:

const token = "abc123";

Para evitar esto, Next te obliga a poner el prefijo NEXT_PUBLIC_ a todas las variables que querramos leer desde el Frontend, el resto van a ser accesibles sin problemas en getStaticProps, getServerSideProps, getStaticPaths y en las rutas del API.

Para usar nuestro token entonces habría que tener un .env con el contenido:

NEXT_PUBLIC_TOKEN=abc123

Y luego en nuestro código usar:

const token = process.env.NEXT_PUBLIC_TOKEN;

Usando next.config.js

Si bien con el .env vas a tener todo lo que necesites la mayor parte del tiempo, es posible definir variables que no necesiten el prefijo NEXT_PUBLIC_ para variables públicas.

Para esto creamos un next.config.js, si no tenemos uno, y en este exportamos un objeto con la key env, esta propiedad debe ser un objeto cuyas keys van a ser variables de entorno, ejemplo:

module.exports = {
  env: {
    TOKEN: "abc123",
  },
};

Con esto, ya no estamos atados al prefijo de NEXT_PUBLIC_, por lo que tenemos que tener cuidado de no exponer en el Frontend valores sensibles.

En producción

Cuando estamos en un entorno de producción, y también en uno de testing, lo mejor es no usar un archivo .env, este debería ser solo para entornos de desarrollo para evitar definir de forma global nuestras variables de entorno.

Para esto, normalmente las plataformas de hosting como Vercel, Netlify, Heroku, AWS, etc. viene con formas de definir estas variables, lo mejor es buscar como funciona en la plataforma que vayamos a usar y usar eso.