I have a single page app (Vue JS) that is built and released as docker image. The docker image is based on the official Nginx Docker image and serves the SPA as static content.

Until now, there was only a single non-development deployment of that SPA, so the URL of the back-end API was hard-coded in the production build parameters of the SPA. Now we are introducing multiple staging environments that each need their own SPA & API deployment. E.g.

  • spa.staging1.example and api.staging1.example
  • spa.staging2.example and api.staging2.example
  • ...

This means that hard-coding the API URL does not work anymore. Creating multiple SPA docker images is also not an option, since there are many staging environments and not all of them are known up-front. This means that the API URL in the SPA Docker image needs to be configurable, preferably with environment variables that are passed into the Docker container.

What are best practices for making SPAs configurable, when there is no dynamic server-side rendering in place?

1 Answer 1


You have three options:

  • Create different static sites that each hardcode one backend. You have dismissed this solution, which is likely the correct decision. (But if you have static sites, why do you even need Docker?)

  • Do use some server-side rendering. For this task, even the simplest text substitution mechanism would be adequate. You could pipe your source code through that template processor.

    Alternatively, you could offer a separate URL that can be used to discover the endpoint – but that would be a highly unusual solution.

  • Change the meaning of these domain names for the users of these staging environments. I.e. let them use a DNS server (or hosts file) that resolves whatever backend you hardcode to the correct staging backend. While you do have this option, it is a very fragile solution that is hard to debug, hard to set up, and has some hilarious failure modes (like accidentally running against your prod backend) unless you have a separate VLAN for your staging environments.

Of all these solutions, using some templating on your server is the least insane approach. If configured properly this will have zero runtime overhead because you only need to render that template once on startup, and can then continue serving that output as a static file. It might even be sufficient to change the ENTRYPOINT command in the Dockerfile to something like:

./fill-in-templates.sh && ./start-nginx
  • 1
    dockerize is very useful for the entrypoint templating approach, and also has other nice features. May 22, 2018 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.