Deployment and Environment Variables — From Working Locally to Going Live

This article covers deployment, the steps that take an app running on your machine to being published, and the environment variables that switch values per destination.

The same app.js runs in two places: your computer and the public server.

When something works on your machine but not on the public server, the cause is outside the code.

The difference between these two places is why it stops working once you publish.

Deployment consists of three stages: build, deploy, and release

Deployment is the work of putting it on a public server so that anyone can use it, and it consists of three stages: build, deploy, and release.

The first stage is the build — gathering app.js and the files it needs into a form the public server can run — and the resulting set of files is the build output.

Settings files used only on your machine stay out of the build output and remain on your machine.

What reaches the public server is only the gathered build output.

Going back to the previous build output is a rollback.

The word deploy sometimes refers only to the middle stage, and sometimes to all three stages.

You will also meet CI/CD (Continuous Integration / Continuous Delivery), which runs these three stages automatically every time you record your code, but only the automation is new; the stages are the same.

Deployment is the name for three jobs together

Deployment is doing three things in a row: gathering, sending, and accepting.

Gathering is the build, sending and starting is the deploy, and accepting requests at the URL is the release. Settings files used only on your machine are not part of what gets gathered, so they never reach the public server.

Development and production environments — the same code, but different surroundings

When an app.js that ran on your machine does not run on the public server, it is not because the code changed.

It is because the environment — the set of computer, OS, runtime, database, and setting values assembled to run app.js — is different.

In the article "What a Development Environment Is," the development environment is a combination of tools; here it is the place where you run things with those tools.

Inside the outer frame there are two environments, and the app.js they run is the same single file.

Only the code is the same; the URL you open, the location of the database, and the API key are all different.

The top three rows are assumptions that held only on your machine.

When it stops working after you publish, suspect the surroundings before the code.

If you log in to the public server and edit the build output or the settings by hand, the next deployment replaces them and your edits are gone.

Fix the app.js in your development environment, and deploy once more after you fix it.

Only the code is the same

An environment is everything assembled around app.js so that it can run.

Your computer is the development environment and the public server is the production environment, and even where the two sides hold things with the same role, the connection targets and the keys have different values, so when it does not work after you publish, start by checking these surroundings.

Environment variables switch values per environment without changing the code

Putting the value outside the code and having the code read only a name is what an environment variable is — a value set outside the program and read by name while it runs.

What you write in app.js is only the name, and on your machine you write the value in .env, a file that lists environment variable names and values.

Your local .env is read only inside the computer where you put it.

Because .env holds API keys, it is kept out of Git, and it is not in the build output either, so it never reaches the production environment.

When a guide says "set the production environment variables," it means registering the same names on the public server side.

With the same app.js, the value it reads changes with where it started.

The value is read at startup, so after you change a value, start it again.

What runs in the left and right boxes is the same app.js.

The only difference is the values placed outside it.

Names in the code, values in the environment

An environment variable is a value placed outside the code and called up by name.

On your machine you write it in a file called .env, and on the public server you register the same name as a setting on that server, so when it does not work after you publish, check first whether you forgot that registration.

Keep secrets only in environment variables, out of the source code and the build output

Among the values you put in environment variables, the ones to watch are secrets — strings that let someone else act as you if they learn them — and API keys and passwords are the main examples.

Environment variables that the frontend reads have their values written into the build output at build time.

The written value reaches the device of anyone who opens the URL, exactly as it is.

Keep secrets only in production environment variables, which stay out of the build output, and register them in the deployment target's settings screen.

The registered value is not in the build output; the public server passes it in when it starts app.js.

If you forget to register it, it starts with the name present but no value.

The registered value exists only on the public server side, and the same value is not copied into the build output or into your local .env.

After you publish, the value itself exists in only one place.

The value is only in the production environment variables, not in the build output and not on the user's device.

How many people can read a given location is covered in the article "Security Points to Watch."

Keep the value in one place only

A secret is a string that other people can use if they learn it.

Writing it in the code gets it gathered by the build and delivered to the user's device, so instead of writing the value, register it as a setting on the public server and write only the name in the code.