Skip to content

S3 Storage ​

Use the S3 Storage node to store workflow data as an object in an Amazon S3 bucket or any S3-compatible storage (for example MinIO or a hosting provider's object storage). It is the simplest way to keep a copy of what a workflow produced: a nightly product export, an archive of every placed order, or a feed file that another system picks up from the bucket.

The node has no operations to pick. Whatever arrives on its Data input is written as a JSON object into the bucket bound to the credential. Path Prefix decides where in the bucket the object lands (for example orders/ or exports/daily/), and Content Type sets the MIME type recorded on the object, application/json by default. Nexus names every object itself as <prefix>/<unix-timestamp>-<uuid>.json, for example orders/1792915200-3f6c2a9e-8d1b-4c55-9a07-2b1e6f0d4c3a.json; you cannot choose the file name.

INFO

Node type: output.s3 · Category: Output

Credentials ​

INFO

This node uses a s3 credential. Create it under Integrations in Nexus before you configure the node.

  1. In Nexus, open Integrations and select Amazon S3.
  2. Enter:
    • Bucket name (the bucket the objects are written to)
    • Region (for example eu-central-1; the region the bucket was created in)
    • Access key ID and Secret access key of an IAM user or role that may write to the bucket. It needs s3:PutObject and s3:PutObjectAcl on the bucket (uploads are sent with the private ACL), plus s3:ListAllMyBuckets for the connection test
    • Custom endpoint only for S3-compatible storage that is not hosted by AWS (for example https://s3.example-provider.com)
    • Session token only if you use temporary credentials
  3. Choose Test connection. A successful test is required before the integration can be saved. The test lists the buckets the key can see; it does not open the bucket you entered or check its region, so a wrong bucket name or region only shows up on the first upload.

Use one S3 integration per bucket. The node writes into the bucket saved on the credential, so it needs no further bucket configuration.

Node parameters ​

Configure this node with these parameters.

Path Prefix ​

Prefix for object keys (e.g., 'orders/' or 'exports/daily/')

  • Type: Text
  • Optional

Content Type ​

Content type for stored objects

  • Type: Text
  • Optional
  • Default: application/json
  • Validated against pattern ^[a-zA-Z0-9][a-zA-Z0-9!#$&\-^_.+]*\/[a-zA-Z0-9][a-zA-Z0-9!#$&\-^_.+]*([ \t]*;[ \t]*[a-zA-Z0-9!#$&\-^_.+]+=[^;\x00-\x1F\x7F]+)*$

Input and output ​

Input ​

PortTypeDescription
DataanyData to store as JSON

Output ​

PortTypeDescription
StoredobjectStorage result with object key and metadata

The node passes its input through unchanged, so the next node receives the same data this node stored. The object key is recorded only in the step's metadata and cannot be used in an expression, so a node that needs to name the file cannot read it from this node's output.

Examples ​

Nightly product export to a bucket ​

Start the workflow with a Schedule Trigger, read the products with a Shopware API Call node, reshape them with a Field Mapping node if needed, and connect the result to this node:

ParameterValue
Path Prefixexports/products/
Content Typeapplication/json

Archive every placed order ​

Connect a Shopware Event Trigger listening for Order placed (ID checkout.order.placed) to this node. Each order lands as its own object under orders/:

ParameterValue
Path Prefixorders/
Content Typeapplication/json

What to do if your operation isn't supported ​

If this node doesn't support the operation you need, use the API Request node to call the service's API directly. Add the authentication headers the service expects and use expressions to pass in data from the trigger or the previous node.

Common issues ​

  • Permission denied by the connected service: S3 refused the upload with an access-denied error. The IAM policy is missing s3:PutObject or s3:PutObjectAcl on the bucket (every upload sets the private ACL, so both are needed), or a bucket policy denies the key. Fix the policy; the connection test does not catch this because it only lists buckets.
  • The requested resource was not found: S3 reports that the bucket does not exist. Check Bucket name on the credential, and for S3-compatible storage the Custom endpoint.
  • The node failed unexpectedly: the most common cause is a Region that does not match the bucket. The connection test does not check the region, so the mismatch only appears on the first upload. Other causes are an access key or secret that S3 does not accept, or S3 throttling the upload. Check the region the bucket was created in, then the key, and update the credential under Integrations.
  • Authentication for the connected service has expired: the credential uses a Session token and the temporary credentials behind it have expired. Use a permanent access key for scheduled workflows.
  • Could not reach the connected service: the Custom endpoint URL is wrong or not reachable from the internet. Leave it empty for buckets hosted by AWS.
  • A failed upload is not retried: every upload writes a new object under a new name, so Nexus does not run the step a second time after a failure, even a temporary one. Run the workflow again once the cause is fixed.
  • Objects pile up under one prefix: every run writes a new object. Use a prefix per export type (exports/products/, orders/) so the files stay easy to find and to clean up with an S3 lifecycle rule.
Was this page helpful?
UnsatisfiedSatisfied
Be the first to vote!
0.0 / 5  (0 votes)