> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/static-service-deployment.md).

# Static service deployment

The simplest, cheapest, and most performant way to deploy your frontend

## What is a static service?

Applications created in Release can have multiple services. These services can be one of two types: A **Docker service** or a **static service**.

A **Docker service** is your standard service built using your Dockerfile. If you can run your service in a Docker container, we can run it in Release. This service type is the most common. However, there are situations where running a service inside a container is not ideal due to cost, performance, or complexity. This is where Release's **static services** step in.

## Static service use case

Your application may have more than one **web server**, each running as its own service in its own container, but all these containers are doing is **building static assets** (like HTML, Javascript, or CSS) and serving them over HTTP/HTTPS.

Running these types of services is common, and running them inside a full-blown Docker container may not be ideal. It may be preferable for your assets to be in a CDN instead of a Docker container.

Behind the scenes, Release will analyze a selected branch in your repository and search for services that are eligible for static service deployment. A repository can have any number of services that are eligible for this optimized deployment.

## Why use static services

| Advantages                            | Disadvantages                                    |
| ------------------------------------- | ------------------------------------------------ |
| ➕ Static assets are deployed to a CDN | ➖ No container to control                        |
| ➕ Smart cache invalidation            | ➖ Doesn't support server-side languages like PHP |
| ➕ No Dockerfile needed                |                                                  |
| ➕ Minimizes cost, maximizes speed     |                                                  |
| ➕ Out-of-the-box SSL                  |                                                  |
| ➕ Supports isomorphic services        |                                                  |

## How to use static asset deployment

When you create a new application using Release's **Create New Application** process, you choose a repository and a directory. Release then checks the repository to see if it contains services that are eligible for static service deployment. If Release finds eligible services, you are given the option of deploying them the standard way through a container or using static service deployment.

If you choose to use static service deployment, Release only requires your build commands and your build directory.

### Adding environment variables

During the **Create New Application** process, you are given the opportunity to add build arguments and static service environment variables. Values placed here are shared between the Docker build process and the static services.

![](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-1e113375069f588d6283b843463bfe1a4056bb0f%2Fcreate-app-add-build-args.png?alt=media)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/reference-documentation/static-service-deployment.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.