Hybrid Docker and static site

This is an example of a more complex application that contains both a set of Docker services and a static Javascript SPA that connects to the Docker services, all in a standalone ReleaseHub environment.

Fork the repository on GitHub

  1. 1.
    Navigate to our react-express-mysql project repository on GitHub.
  2. 2.
    Click Fork in the top-right corner of the page.

Create and configure a new application in ReleaseHub

  1. 1.
    Log in to your ReleaseHub account.
  2. 2.
    Click Create New Application on the Getting Started page.
  1. 1.
    Refresh your repositories by clicking on the circle on the right-hand side of the list of repositories.
  1. 1.
    Select the react-express-mysql repository and use the default main branch.
  1. 1.
    ReleaseHub will analyze and detect the different service types for the application. Should ReleaseHub detect that it's possible to use more than one service type, you will need to manually select the service type you prefer. For this example, ReleaseHub should present:
  • Docker service type for backend.
  • Docker service type for db.
  • "No service type selected" for frontend.
Since our frontend service can be deployed with either a static service or with Docker, ReleaseHub does not default to either. Select Static for frontend.
You don't need to modify the backend and db Docker service parameters during set up, as ReleaseHub infers the set up from the docker-compose.yaml file found in the repository.
With frontend set to Static, ReleaseHub will automatically detect the build parameters from the package.json file in the repository. It locates the frontend service in the frontend directory, builds it with the yarn build command, and copies the build files into the build directory. Read our static service deployment guide for more information on building and deploying static services.
You can modify the application name or use the default, which is the name of your repository.
  1. 1.
    Click the Generate App Template button to proceed.
  2. 2.
    Now you can view the Application Template and modify it if necessary. If you aren't familiar with the ReleaseHub Application Template yet, take a look at the documentation to understand how the template is used to initialize your application and any subsequent environments that are generated from it. Click Save & Continue to move to the next step.
  1. 1.
    On the Build & Runtime Configurations page, you can add build arguments, modify the default environment variables, or apply Just-In-Time file mounts if you need to. For this example, we'll go ahead and click Start Build & Deploy without making any changes.
  1. 1.
    While ReleaseHub is building and deploying the app, you will be directed to the App Dashboard where your deployment will show under "Activity". You can click on Builds or Deploys to view status logs of your application.
Once the Environment is completed, you can click on it to see the details.

Map an environment-specific environment variable

On the Environment Details page, scroll down to the "Instances" section.
Here you can see that the environment deployed successfully, all services are running, and both the frontend and backend URLs are live.
However, the application isn't communicating from the frontend to the backend. You can see this issue by clicking on the frontend URL and inspecting the network traffic on the page.
Let's take a look at the frontend code to understand why this is happening. Here's a snippet of the frontend code from App.js in our application's repository:
function App() {
const [message, setMessage] = useState();
useEffect(() => {
.then(res => res.json())
.then(res => setMessage(res.message))
}, [setMessage]);
return (
<div className="App">
<header className="App-header">
<img src={logo} className="App-logo" alt="logo" />
<p>{message || "Loading..."}</p>
Edit <code>src/App.js</code> and save to reload.
rel="noopener noreferrer"
Learn React
On line 4, we can see that fetch is attempting to pull data from an environment variable set by React labeled REACT_APP_BACKEND_URL. This environment variable is intended to hold the URL of the backend service. However, since URLs are dynamic in ReleaseHub, this URL is not accessible yet. We need to apply an environment variable mapping in the environment's configuration.
Return to the Environment Details page and navigate to the Settings tab.
Click the Edit button next to "Environment Variables" to open the editor.
Here we added the following to lines 2 and 3:
This instructs ReleaseHub to map REACT_APP_BACKEND_URL to the dynamically created BACKEND_URL_INGRESS variable that is set to the backend service for this application. Once you have made this edit, click Save As New Version.
Now we can see that a new version of the environment configuration has been saved, but not yet deployed.
Click Apply in the "Apply Latest Configuration" section to deploy the environment and set the environment variable mapping.
When the deploy has finished, click on the environment name and go back to the Settings tab. Here you'll see that the latest environment configuration version 1.2 matches the currently deployed environment configuration version. You can read more about how ReleaseHub environment versioning works in our guide.
Go back to Details and click on the frontend URL in the "Hostname URLs" section to view the deployed preview environment.
You should see a "Hello from MySQL" message render in the browser. You can verify that the frontend service is communicating with the backend service by inspecting the network traffic. The API returns the version of MySQL running, which is displayed to the screen.

Map environment variables in default environment variables

The environment variable mapping we added is an environment-specific environment variable configuration that only applies to this single instantiated ephemeral environment. To apply this environment variable mapping to all environments created moving forward, we need to include the mapping in the default environment variable configuration.
To do this, click Settings under the application in the sidebar.
This will take you to the application's default settings.
Click Edit next to "Default Environment Variables" to add the environment variable mapping to the configuration for all your environments.
Add the mapping to lines 2 and 3 as we did previously:
Click Save As New Version.
You should see the new app version roll to "2" in App Settings.
All new environments created on ReleaseHub will now automatically receive this new version 2 mapping scheme.

Test default environment variables in a new ephemeral environment

We can test whether our new default configuration is applied by creating a new ephemeral environment.
  1. 1.
    In the sidebar, click Environments.
In the Environments page, you can see the previously instantiated environment.
Let's create a new environment that will automatically inherit our environment variable mapping.
  1. 1.
    Click Create New Environment.
  2. 2.
    In the new environment dialog, select the main branch and Ephemeral for "Environment Type".
Click Create Environment.
This will create and deploy a new ephemeral environment tracking the main branch.
Once the environment has been deployed, you can view its details to see if our environment variable mapping has been applied.
Click on the environment name from the Deploy Info screen. On the Environment Details page, click on the Settings tab to see the new environment that was generated using the edited global application configuration. The "Currently Deployed Version" has the new version number of "2.1".
To verify that the default environment variable mapping was applied to the environment, click Edit next to "Environment Variables". You should see the mapping in the code editor.
Return to the Environment Details screen and click into the new frontend service hostname URL. You should see the "Hello from MySQL" message rendered as it should be.
Navigate back to Environments.
You should see both your environments listed.