> 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/cli/remote-dev.md).

# Remote development environments

With Release remote development environments, you can "mount" an ephemeral environment to your local computer and work on it as you would if you were developing locally.

You work in your preferred IDE and when you save, Release automatically syncs your changes to the server. If your server is configured with live reloading, your changes will appear in near real-time.

You can mount your database to a local port and use your favorite database GUI tool to interact with it.

## Setting up a remote development environment

We'll guide you through setting up a Release remote development environment with just a few lines of YAML.

### Prerequisites

To set up a remote development environment, you need a working, deployed application on Release. If you don't already have a working application, follow [getting started](/readme.md) in the Release documentation and then create one of the Release example applications. In this guide, we use the [full stack voting app](/guides-and-examples/common-setup-examples/example-voting-app.md) to demonstrate setting up a remote development environment.

You will also need to have the [Release CLI](/cli/installation.md) and the [AWS CLI](https://aws.amazon.com/cli/) version 2.8.11 or higher installed.

### Configuring your Application Template

The [Application Template](/reference-documentation/application-settings/application-template.md) defines a top-level block named `development_environment` in which you can specify how the application should behave in development mode.

Here is an example `development_environment` block from the full stack voting app:

```yaml
development_environment:
  services:
  - name: vote
    command: python app.py
    sync:
    - remote_path: "/app"
      local_path: "./vote"
    port_forwards:
    - remote_port: 80
      local_port: 5000
  - name: result
    command: nodemon server.js
    port_forwards:
    - remote_port: 80
      local_port: 5001
    sync:
    - remote_path: "/app"
      local_path: "./result"
```

If you're following along with an example full stack voting app, add this code to the top level of your Application Template and click **Save as new version**.

### Using a different container image for development

You might prefer to use a different container image when running a service in development mode. This is useful if you have development-only tools or dependencies you'd prefer not to include in your production images.

To use a different container image for development mode, first add a top-level `builds` stanza to your Application Template specifying the Dockerfile or multistage build target you would like to use:

```yaml
builds:
- name: vote-dev
  context: vote
  dockerfile: "./Dockerfile"
  target: dev
```

Then specify an `image` for your `development_environment` service:

```yaml
development_environment:
  services:
  - name: vote
    command: python app.py
    image: my-org/release-example-voting-app/vote-dev
    sync:
    - remote_path: "/app"
      local_path: "./vote"
    port_forwards:
    - remote_port: 80
      local_port: 5000
```

## Connecting to a development environment

Once you have configured your application for remote development, run `release auth login` in the Release CLI.

Select the app you want to use with `release apps select`.

In the root of your local copy of the repository you want to debug, kick off the remote dev process with `release dev start --environment ID_OR_NAME`.

Once everything turns green, you should be able to access <http://localhost:5000> and <http://localhost:5001> returning the `vote` and `result` services respectively (or whichever ports you configured for your application).

Now you can edit files locally, refresh the browser, and see your changes. You can view and tail the logs in the `~/.releasehub/dev/` folder to see the output of the different commands.

## Debugging a development environment

The commands tail their output to log files in `~/.releasehub/dev/ENV_ID/`. Use `tail -f log-servicename.txt` to see the output of the command running on the server.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.release.com/cli/remote-dev.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.