Docker image to test deployment to Netlify

Update

Apologies, I just found netlify-cli and netlify dev, which seems to get us most of the way there, but if I use the sed technique from the documentation (https://docs.netlify.com/configure-builds/file-based-configuration/#inject-environment-variable-values), in the [dev] block, it permanently changes netlify.toml. I would need to use the sed backup feature and replace netlify.toml with that once the server goes down, it seems. However, there doesn’t appear to be a way to add a teardown script, yet.

Original question

I am aware there is a Netlify build Docker image for testing, but how about a deploy one?

The biggest use case here is in testing redirects and build switches which can be set in the netlify.toml file. It is currently impossible to see if certain redirects work as expected without a complete deploy to Netlify, which soon eats up build minutes.

It would be great to be able to set up a local Docker cluster with something that closely mimics a Netlify deployment, with config switches for the dev environment.

Even something akin to the Zeit now-dev would help solve the problem.

Thanks for your time

Hey @time,

If you simply aim to test redirects in dev, you need not worry about injecting env variables as redirects will still work as anticipated.

Here’s a link to some further reading on Dev. However, if I’m blatantly missing something, please do get back to us!

Thanks for the reply.

I probably wasn’t very clear in my post as I wrote while discovering features. The referenced documentation gives an example of wanting to replace a variable e.g. API_LOCATION, which one could then replace with different values for dev, staging, and production. In this case, you’d have a redirect looking something like the following:

[[redirects]]
  from = "/api/*"
  to = "API_LOCATION/api/:splat"
  status = 200
  force = true

In which case, you’d always want to replace API_LOCATION with an actual location. It seems using sed is still the only way to do this, which means restoring a backup after each run of netlify dev, unless I have missed something.

Yes, your assertion is correct - there is no better BUILT IN way to handle placeholders like yours in netlify dev. Maybe instead of modifying the file directly, you make a startup script like this:

sed s/PLACEHOLDER/${API_LOCATION}/g < input-toml > netlify.toml && netlify dev

?

But I’d also think that your API_LOCATION would stay pretty consistent in local test, and you could .gitignore the file for the most part to prevent your git client from uploading it when you push.

Interesting solution, this could be another way to separate builds by generating the netlify.toml from different sources. However, the config still has to be part of the repo to be read by the Netlify build servers, does it not? If not, maybe all we miss out on are the build-time directives like [context.production].

Thanks again for the suggestion. I’ll keep working at it in the background while we come up with a workflow that feels effective.

Hi, @time, if I understand the question, you are asking about how to keep the secrets out of the repo. Is that correct?

If so, the environment variable can be set locally however you prefer. For the Netlify build system, you can add environment variables in the UI to keep them out of the repo itself. This is done under “Site Name” > Settings > Build & deploy > Environment.

The build command can be set in netlify.toml or the UI (the TOML file takes precedence if both are used).

If there are any other questions about this, we are happy to answer.

Thanks for the reply.

The question was, in summary, about how to keep netlify.toml configs separate between dev, staging, and production environments. The sed solution in the docs would modify the file permanently while developing, meaning we have to roll it back to its pre-sed form each time.

If you have any other good ideas about how to do this, I’d be very grateful.

1 Like