> For the complete documentation index, see [llms.txt](https://docs.contextual.io/documentation-and-resources/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/stream/write-cloud.md).

# Write Cloud

Writes content from the message to a file in a connected cloud storage location.

**Write Cloud** takes a value from the message and stores it as a file in cloud storage.

Use a **Write Cloud** node in your Flow to persist something the Flow has produced: an export for another system to collect, a generated report, a copy of an incoming payload, or the result of a stream that has been collected back into a single value.

Write Cloud does not open a source stream and does not require *Sink Collect*. It works in an ordinary row.

To configure a **Write Cloud** node in the *Flow Editor*, drag it from the **Stream** group in the Palette to the Workspace canvas, then double-click the node to open and configure its behavior.

## General tab

* **Name** — optional display name for the node in the editor. By default the node shows a label of "Write Cloud"; the value you provide here replaces it.
* **Config** — the tenant configuration. Defaults to the current tenant.
* **Connection** — the storage connection to write to. Selected from the connections configured for the tenant. Required.
* **Remote Path** — the path of the file to write. Required.
* **Input** — the message property holding the content to write. Defaults to `msg.payload`.
* **Headers** — an optional list of key and value pairs, added with the **add** button. Each row takes a header name and a value. The value is a typed input, so it can be entered directly as a string, number, boolean or JSON, or resolved from a msg, flow, global, or environment value, a JSONata expression, or a timestamp.

## Remote paths

For AWS S3 or Azure Blob, if the connection does not already specify a bucket or container, **Remote Path** must begin with it, followed by the file path, using `<bucket-or-container>/<path/to/file>`. For example, `test/hello.txt` selects bucket or container `test` and file `hello.txt`.

For SFTP, **Remote Path** is passed through unchanged and must be a valid path on the remote server.

Writing to a path that already holds a file **overwrites it in place**. No error is raised and no confirmation is requested.

List Cloud fields vary by provider. Azure can return creation time, MD5, and content headers. AWS listings do not return `createdAt` or content headers and may omit `contentMD5` for multipart objects. SFTP listings return only `path`, `size`, and `updatedAt`.

## Preparing the content

**Input** is passed to the selected provider without serialization. Use a string, Buffer, or readable stream; serialize objects and other values before this node.

A Template node placed before Write Cloud is a convenient way to produce text, and unlike the Inject node it accepts multiple lines. Set its property to `msg.payload`, its format to **Mustache template**, and **Output as** to **Plain text**.

Text in a Mustache template is written literally, but `{{ }}` is a variable reference. Entering `{{"hello world"}}` looks for a variable of that name, finds nothing, and writes an empty value. To write the words themselves, enter them without braces.

## Setting headers

Each **Headers** row pairs a name with a typed value, so a header can be fixed in the editor or drawn from the message at runtime.

For AWS S3 and Azure Blob, supported content headers such as `contentType` are normalized and applied. When `contentType` is omitted, the provider derives it from the file extension.

List Cloud output varies by provider. Azure includes available content properties. AWS list operations do not return content headers, and SFTP ignores **Headers** and returns only `path`, `size`, and `updatedAt`.

## Source tab

The **Source** tab controls how the node behaves when it is processing a source stream rather than a single message.

* **Parallelism** can be set to None, Ordered, or Unordered
* **Max** — the concurrency ceiling for Ordered. Unordered can currently run one additional operation.

These are the same controls the Object nodes provide, such as *Put Object* and *Query Object*. A Write Cloud node placed inside a source stream can therefore write several files concurrently rather than one at a time.

The tab itself notes: *Configurations in this tab are only active when this node is in a source.* Outside a source stream the node processes a single message, and **Parallelism** and **Max** have no effect.

## Example

A Flow writes a short text file to storage.

```
[GET] /write → Template → Write Cloud → HTTP Response
```

### Prepare the content

Add a Template node with **Property** `msg.payload`, **Format** Mustache template, and **Output as** Plain text. Enter the text to write in the template body:

```
hello world
```

### Configure the Write Cloud node

Set **Connection** to the storage connection, **Remote Path** to `test/hello.txt`, and leave **Input** as `msg.payload`.

### Confirm the file was written

Request `/write`, then use a *List Cloud* node against the container. The new file appears with its path, size in bytes, and a contentType derived from the extension.

A Log node placed after Write Cloud shows the written content still on the message.

## What the node returns

On success, Write Cloud preserves the configured **Input** value and passes the message downstream. It does not add a write result. In source mode, it updates the internal source pipeline.


---

# 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.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/stream/write-cloud.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.
