Your Own Storage in Workflows
Part of the MountDev Ops Workflows documentation. Updated November 14, 2026
MountDev Ops Workflows documentation | Updated November 14, 2026
Our Commitment
MountDev Ops is built security first. Your business data belongs to you, and you can export all of it at any time. We never use analytics or tracking of any kind inside MountDev Ops.
Every update passes all 4,137 automated checks before it ships, and every screen change is walked through before release.
The Storage Connection
A workflow can keep files in a bucket you own, such as backups, exports, and large files. Any storage service that speaks the S3 standard works: Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO, and others. An owner or admin adds it in Settings, Connections, Connected Services, then Connect a Service, then Your Own Storage.
- Address: your storage service's address, such as https://s3.us-west-2.amazonaws.com. It starts with https:// and has nothing after the name. A private address is refused.
- Region: where the bucket is, such as us-west-2. Some services use auto.
- Bucket: the bucket's name.
- Access key ID and Secret access key: the key you made for this bucket in your storage service. Give it only the rights it needs on this one bucket.
- Check Now writes a tiny test object, removes it, and says in plain words what happened: it works, the key was not accepted, the bucket was not found, the clock is off, or the address could not be reached. It leaves nothing behind.
The secret access key is sealed in your account and is never shown again, returned, or logged. The access key ID is not secret, so it is shown again to tell which key is saved. Requests are signed inside your own workspace and nothing about your storage or your files goes anywhere else. Your storage service bills you for what you store and move. What your workflows do in your bucket is also counted in your Usage: calls made, bytes put, and bytes removed (counts and sizes only, never a name or contents). Any price for it is set as your account's own data, never in the product.
If your storage only accepts calls from listed addresses, turn on Send From a Fixed Address on the connection (see Fixed Outbound Address). Check Now and every step that calls your storage then go out only through the fixed address, never directly. The links below are used by the other app, so they go from that app's address, not ours.
The Steps
Each step names the storage connection, can be tried with Test Run (which sends nothing and deletes nothing), and counts as one step. Names are written like folders, such as backups/daily/site-1.zip, with no slash at the start.
- Put an Object (action
storage.put_object): writes text, up to 100,000 characters, under a name. It refuses to replace an object that is already there. A try repeated after a lost answer is the same call, so it never fails because of itself. For a large file, use an upload link instead. - Replace an Object (action
storage.replace_object): writes text over a name that is already there. Replacing counts as a deletion, so it waits for a person to confirm it every time, and it has no once-only approval. - Make a Short-Lived Upload Link (action
storage.upload_link): makes a link that lets another app send one file to one name in your bucket, for 1 minute to 24 hours (15 minutes if you do not say). The workflow never carries the file: the other app sends it straight to the bucket, so a file of any size works. The link is made in your workspace without calling your storage. Anyone who holds the link can write that one name until it ends, so pass it only to the app that needs it. It cannot limit the file's size; use your storage's own bucket rules for that. - Make a Short-Lived Download Link (action
storage.download_link): the same for reading one object, 1 minute to 24 hours. It checks the object is there first, and answers its size. - List Objects (action
storage.list_objects): the names, sizes, and times of objects under a folder, up to 1,000 at a time. Older than days keeps only objects older than that many days. When there are more, the answer says so and gives a continue from value to ask for the next part. - Delete an Object (action
storage.delete_object): removes one object. See the next section.
The run history keeps counts and sizes. The names and links go on to the steps after them, and the links are never written in the run history.
The Delete Rule
Delete an Object and Replace an Object always wait for a person to confirm them, however the workflow was written. A card is made for every run and the run waits.
There is one exception, for backups, and it is only for Delete an Object. A delete step that is limited to one folder (Only Under) and to objects older than a number of days (Only Older Than Days), both typed into the step itself, is approved once, when the workflow is turned on. The card you see when you turn it on names the bucket, the folder, and the days, for example: "Once it is on, this workflow will delete objects older than 30 days under backups/daily/ in the bucket acme-test-backups, every time it runs, without asking each time." After you say yes, that step runs without a card each time.
What keeps this safe:
- The limit is checked on every run, not only on the card. Before it deletes, the step reads the object's own last modified time from your storage. A name that is not under the folder, or an object that is not old enough, is refused and nothing is deleted. A name taken from an earlier step cannot get around it.
- The folder must end with a slash, so backups/ never matches backups-private/. The days are a whole number from 1 to 3,650.
- The limits must be typed into the step. If the folder or the days come from an earlier step, or only one of the two is given, the step keeps its card every time.
- Any change to a limited delete, or a new one, turns the workflow off, even when a person saved it, so turning it on asks again. Removing one needs no new yes.
- A person turns the workflow on (from a screen with the confirmation, or by saying yes to the request your AI assistant made, which names the same folder and days). A run of a workflow that is off still waits for a card, and a test run never deletes.
Keeping a Bucket Tidy (Retention)
Retention Rules as a separate feature are planned for later (Planned). Today a workflow does it:
- Start it on a schedule.
- List Objects under the folder with Older than days set.
- Repeat for each object in the list, and run Delete an Object with the same Only Under and Only Older Than Days.
- Mark a record, or tell people, when it is done.
Turn it on once and say yes to the card. It then keeps the folder to the days you chose, and never touches anything else in the bucket.
When Something Fails
- A busy or unreachable storage (408, 429, 5xx, or no answer within 15 seconds) is tried again by the workflow's own backoff.
- A key that was not accepted, a bucket that was not found, a clock that is off, or a service that sent the request somewhere else fails the step with a plain sentence. No sentence ever holds the key.
- With the fixed address on and no fixed address set up for your region, the step fails and sends nothing any other way.
