Automatically Archiving and Classifying Files in n8n with AI and S3 Storage

A Google Drive "Archives" folder creeping toward its quota, a self-hosted instance's disk filling up with three-year-old PDFs, or a legal obligation to retain invoices for ten years without letting them clutter the active workspace: all three situations call for the same fix — archiving to a dedicated object store instead of piling files up in the day-to-day tool. n8n can drive that transfer end to end — classification, upload, logging, cleaning up the source — with no external script and no paid third-party service beyond the storage itself.

The S3 node and the S3 binary storage mode: two different things

Before going further, a clarification that avoids a classic mix-up. Our guide on large files in n8n explains that the binary storage mode N8N_DEFAULT_BINARY_DATA_MODE=s3 — an internal setting that offloads to S3 the files n8n handles while a workflow is running — is Enterprise-only. This guide is about something else: the S3 node, which exposes Upload, Download, List, and Delete operations on a bucket just like any other integration node (Google Drive, Dropbox). This node is available in the free Community Edition, exactly like the Google Drive or Supabase node. It's this node you use to archive a file at the end of a pipeline, not the internal storage mode.

Why archive outside your day-to-day working tool

A shared Drive or Dropbox folder is built for active collaboration, not long-term retention: the quota keeps growing, the cost per GB is noticeably higher than dedicated object storage, and finding a four-year-old document in a folder structure that's changed three times becomes an archaeology exercise. Object storage (Amazon S3, but also cheaper S3-compatible alternatives like Backblaze B2, OVH Object Storage, or Scaleway) typically costs a few cents per GB per month, with a stable key structure you define once and for all.

The problem centralized archiving solves isn't new. A landmark study in personal information management by Bergman, Beyth-Marom, and Nachmias (The Project Fragmentation Problem in Personal Information Management, CHI 2006 — see on Google Scholar) shows that users who scatter files related to the same project across multiple locations and formats (documents, emails, bookmarks) struggle to find them again later, whereas centralized, consistent storage noticeably eases later retrieval. An automated archiving pipeline enforces exactly that consistency — an identical key structure, systematic naming — without depending on any individual's discipline.

Step 1 — Detect and classify the document before archiving

The trigger depends on the source: Google Drive Trigger or Dropbox Trigger for a watched folder, Read/Write Files from Disk for a self-hosted instance archiving a local directory, or directly at the tail end of an existing pipeline (extracted invoices, already-classified contracts). If the file isn't already categorized upstream, a Basic LLM Chain with a Structured Output Parser determines the category exactly as described in our guide on classifying incoming documents with AI — the same logic that powers PDF invoice extraction works here to decide which logical "folder" of the bucket the file belongs in.

That category is used to build a readable, sortable S3 key, along the lines of:

archives/{category}/{year}/{month}/{id}-{original-name}.pdf

A schema like this sorts naturally by category and then by date in any S3 client, with no need for an external metadata database for a rough search.

Step 2 — Set up the S3 credential (AWS or compatible)

n8n's S3 credential asks for an access key, a secret key, and a region. For a provider other than AWS, the Endpoint field must point to that provider's URL (for example s3.eu-west-1.wasabisys.com for Wasabi, or your instance's address for a self-hosted MinIO); some providers, MinIO in particular with its default configuration, additionally require the Force Path Style option enabled on the credential so requests reach the right bucket. That's the setting most often forgotten when migrating from AWS to self-hosted storage.

On the S3 node itself, the Upload operation accepts binary data straight from the previous node — no need to write the file to disk in between. For a large binary (several hundred MB), switch the instance to filesystem mode for internal binary storage — see our guide on large files — so the file doesn't sit entirely in RAM for the duration of the upload.

Step 3 — Confirm, log, and only then clean up the source

The S3 node's Upload operation returns an acknowledgment (ETag, byte size). It's that response — not merely the absence of an error — that should gate what happens next: an IF node compares the returned size against the source file's size before allowing anything irreversible. Never delete or move the source file just because the S3 node didn't fail outright — a partial network error can produce a truncated object without n8n spontaneously detecting it.

Once that check passes, a Supabase node logs the operation to a dedicated table (archived_files: original name, S3 key, category, size, date, hash) following the same pattern described in our n8n-Supabase connection guide. That table doubles as a safeguard: it's what lets you check a file hasn't already been archived before triggering another upload — the same idempotency-by-unique-key logic described in our article on idempotent webhooks, applied here to a content hash instead of an event identifier. Only at this point can the source file be moved to a temporary trash folder (never deleted outright) or removed, depending on how cautious you want to be.

Retention policy: think beyond the simple drop-off

An S3 bucket isn't just a passive storage space: lifecycle rules, configurable directly in the provider's console, let you automatically move an object to a cheaper storage class (Glacier on AWS, "cold archive" equivalents elsewhere) after a set delay, then permanently delete it once the legal retention period ends. For an organization under traceability obligations — the typical case for the Compliance & Audit Pack ($149), whose GDPR audit trail already logs every sensitive action to Supabase — this retention policy is set once in the bucket and applies afterward with no further intervention from the n8n workflow, which only has to drop files in the right place.

How much this storage costs, and why it's reliable

Standard object storage runs around $0.02–$0.025 per GB per month at most S3-compatible providers, not counting egress fees, which are generally higher than ingress — worth watching if you plan to frequently re-download archives rather than let them sit. That perceived reliability of object storage isn't just a marketing claim: a study by a team at Google (Ford, Labelle, et al., Availability in Globally Distributed Storage Systems, OSDI 2010 — see on Google Scholar) analyzed the real-world failure modes of large-scale distributed storage systems at scale and found that geographic redundancy and multi-level replication — exactly the architecture S3 and its equivalents rely on — sharply reduce the risk of data loss compared to a single local disk, such as that of a self-hosted n8n instance.

Pitfalls to avoid

• Uploading before verifying the classification succeeded: if the AI step fails or returns low confidence, it's better to route the file to human review (as described in our document classification guide) than to archive it under the wrong category, hard to fix once the S3 key is set;
• Uploading a whole batch with no pacing: a bulk import of several hundred files at once saturates both the S3 API and the instance's memory; a Loop Over Items with sensible throttling avoids 429 errors from the provider;
• Not planning a retry on the upload: a transient network error on a large file shouldn't fail the entire pipeline with no further attempt — see our guide on HTTP Request retry and timeout, directly transferable to the S3 node via its own retry setting.

Wrapping up

An automated archiving pipeline comes down to four steps: classification to build a consistent key, upload to an S3 or compatible bucket with result verification, logging to a table that also guards against duplicates, and cleaning up the source only once the upload is confirmed. It's the same discipline applied to document ingestion in the RAG Assistant Pack ($119): never trust the absence of an error, always verify the result before acting irreversibly on the source file.