Getting started
There are four ways to work with STRG, and they all lead to the same place: one account, one set of buckets and one set of access keys. That means there is no wrong place to begin. Most people start with whichever feels most familiar and add the others when they need them - a bucket created in the dashboard is right there for an agent or an S3 tool a minute later.
Whichever way you start, your account needs a card before its first bucket or access key. It goes on Billing in the dashboard, and a $1 hold checks it and is released at once - nothing is charged until there is storage to bill.
Which should I pick
Each row is a common starting point and the way in that suits it best.
| You want to | Start with |
|---|---|
| Create buckets, upload and browse files, and manage settings by clicking | The dashboard |
| Let an AI agent create buckets, read and write objects, and create keys for you | The MCP server |
| Point existing S3 tools, SDKs or applications at STRG | The S3-compatible API, after creating a key in the dashboard |
| Create, list and delete access keys from scripts, CI or your own tools | The REST API, after creating a key in the dashboard |
The dashboard
The dashboard is a web application at https://app.strg.com, and it is where everything can
be seen and changed by clicking: buckets, objects, access keys and bucket settings such as CORS
rules, lifecycle policies and Object Lock. It is also the natural first stop for setting up an
account, because the card and the first access key are a few clicks away.
| Suits | Anyone setting up an account, and anyone who prefers a browser to a command line |
| You need | An email address or a GitHub account. Signing in and signing up are the same screen: a new address or GitHub identity gets an account on its first sign-in. There is no password - we email you a six-digit code. A card, added on Billing, before your first bucket or access key |
| Next | Getting started with the dashboard walks through it |
The MCP server
The MCP server, at https://mcp.strg.com/mcp, gives an AI agent its own tools for your
storage, so it can do the work for you without any API integration. Through it an agent can list
and create buckets, run S3 operations, create presigned URLs, create, list and revoke access keys,
and search this documentation - handy for an agent keeping its memory in a bucket, or for asking
your assistant to set up storage for a new project.
| Suits | AI agents and the people who run them |
| You need | An MCP client that supports remote servers over HTTP. The client either opens a browser where you sign in - or sign up - and choose what the agent may do, or sends an existing access key that holds the Use the MCP server permission. Connecting through the browser creates an access key, so an account without a card is asked to add one first - that is something only you can do, not the agent |
| Next | Getting started with MCP. With an account already, Connect your own agent in the dashboard's top bar shows the setup for your client, ready to copy |
The S3-compatible API
Each region has an S3-compatible endpoint, https://s3.<region>.strg.com, so the AWS CLI, the
AWS SDKs and other S3 tools work with STRG as they are - an existing application or a
nightly backup only needs a new endpoint and a key.
| Suits | Applications, scripts, backups and any tool that already speaks S3 |
| You need | An access key and the region of your bucket. The regions are us-east-1 (US East) and eu-central-1 (EU Central) |
| Next | The S3 API overview covers endpoints, supported operations and differences from Amazon S3 |
The S3 API has no getting-started guide of its own, because most S3 users begin in the dashboard anyway: that is where a bucket and an access key are created. Getting started with the dashboard ends with exactly that step, configuring the AWS CLI, rclone and an SDK, and Access keys has every permission a key can hold.
The REST API
The REST API is a JSON API at https://api.strg.com/v1/ for managing access keys: listing them,
looking one up, creating one and deleting one. It is there so that keys can be handled by code -
a CI job that creates a narrowly scoped key, uses it and deletes it afterwards, for example. It
manages access keys only; buckets and objects are the S3 API's.
| Suits | Scripts, CI pipelines and tools that create a narrowly scoped key for a job and delete it afterwards, or clean up old keys |
| You need | An access key that holds the Manage access keys through the API permission, created on the Access Keys page in the dashboard, sent as Authorization: Bearer <access key id>:<secret>. A key it creates can never have more access than that key has. Creating a key needs a card on file, as in the dashboard |
| Next | The REST API overview covers authentication, errors, paging and the operations |