You can upload your first object by following our documentation here.
All you need to create a shareable URL is the linksharing base URL for your region, a public, read-only access key from the Gateway MT of the same region, and the path to your object or bucket. For a shortcut, Uplink CLI will generate the shareable URL for you. Otherwise, you can build your link like so:
<base url>/s/<access key>/<path sans sj://>
The Storj DCS service allows you to host static websites along with multimedia streaming, large file distribution, and other web-delivered assets.
Since your webpages and assets are simply objects stored on the network and there is no server/database, Storj DCS does not support the hosting of dynamic websites. However, you can store all of your unchanging assets on Storj DCS and reference them from your dynamic site that is hosted on an external compute service of your choice.
When your data is uploaded, each object is encrypted, then broken into 64 MB Segments, then each Segment is erasure coded, meaning it's broken into 80 pieces, of which only 29 are required to reconstitute an object or segment. Each of those 80 pieces is then uploaded directly, peer-to-peer, to statistically uncorrelated storage nodes. The erasure coded redundancy means that 51 of those nodes (operated by different people, in different locations, with different power supplies and internet connections. If too many nodes fail or leave the network, the network can repair the missing pieces.
Storj DCS is a secure and private object storage service. While there are several different ways to interact with the service, including an S3 compatible gateway, CLI, developer library and tools like FileZilla, Rclone, Restic, Duplicati and more, you are responsible for keeping your encryption keys safe.
You can generate an Access Grant in the Satellite Admin Console, or you can use either our Go Library or the CLI. In general, you use the Satellite Admin Console web interface to create an Access Grant that you can then use to set up whatever client tool you are using. The CLI, client library or other client tool can then use that Access Grant to interact with the Storj DCS service, or create restricted Access Grants - child Access Grants of the parent created in the Satellite Admin Console.
Access Grants created using the Satellite user interface my be deleted using the Remove button on the Access page. Check the box next to the Access Grant(s) you want to delete, then click the Remove Selected button and follow the prompts.
If you created a child Access Grant client-side, using the CLI, the client Go library, or any other client-side tool or implementation, you can't "delete" the access because, by design and for enhanced privacy and security, the Satellite is not aware of Access Grants created in a client. When presented with any Access Grant, the Satellite can only verify whether the Access Grant is valid for the resource being requested. For this reason, Access Grants that have been created client-side cannot be deleted, but must be revoked instead.
You can learn more under Concepts for Access Grants.
Your encryption keys effectively are your data. If you've lost the encryption key associated with an Access Grant, but you still have the Access Grant, DO NOT DELETE OR REVOKE that Access Grant. An Access Grant will continue to work until revoked or deleted. An Access Grant contains a serialized API key, encryption key, and the Satellite that holds the metadata for an object, but what is serialized in the access grant is derived from the passphrase - the passphrase is not stored in the access grant directly. Of course, that encryption passphrase is not stored by any Storj DCS service.
The safest approach would be to download your data with the working Access Grant, then create a new Access Grant with a new encryption passphrase and re-upload the data. Be sure to save that encryption passphrase in a secure location! As long as you have the encryption passphrase, you can generate new Access Grants that will work with pre-existing data.
If you've lost the Access Grant and you don't have a backup of the encryption passphrase, you will not be able to decrypt your data and it is effectively lost.
Access Grants can be created either in a browser or with the CLI or library, they can be further restricted, client-side creating additional hierarchically derived Access grants. Since these restricted Access Grants are managed client-side through delegated authorization, no server has any registry that these Access Grants even exist. While this gives developers a powerful tool kit to create more private and secure applications, shared access also needs to be revoked. The Storj DCS service has an API for revoking Access Grants via a revocation list.
You can learn more under Concepts for Access Revocation.
You can generate a restricted Access Grant from the Satellite user interface, using the CLI, or using the client Go Library. While the possibilities for access controls that can be encoded in a caveat are virtually unlimited, the specific caveats supported on Storj DCS are as follows:
Specific operations: Caveats can restrict whether an API Key can perform any of the following operations: Read, Write, Delete, List
Bucket: Caveats can restrict whether an API Key can perform operations on one or more Buckets
Path and path prefix: Caveats can restrict whether an API Key can perform operations on Objects within a specific path in the object hierarchy
Time window: Caveats can restrict when an API Key can perform operations on objects stored on the service
For some sample Go code around access-restriction, check out: https://godoc.org/storj.io/storj/lib/uplink#example-package--RestrictAccess
When you decide to become a paid customer of Storj DCS, you can choose to pay with a credit card or using STORJ token. The process for adding a payment method is covered in our Billing Documentation.
The default usage limits for a new account are published on the Usage Limits section under Concepts.
The default usage limits may not be suitable for all projects. Usage limits may be increased for paid tier accounts. A valid credit card or a sufficient balance of STORJ token relative to the usage limit increase requested as the payment method must be added before a usage limit request form may be submitted. Please note that you will be required to verify email address on account by making a help desk account before requesting a limit increase.
For more information on rate limits view the Limits section under Concepts.
For detailed information on how billing and payment work on Storj DCS, please see the Billing & Payment section of this documentation.
For detailed information on how to remove a credit card from the Storj DCS service, please see Deleting a Payment Method under the Billing & Payment section of this documentation. Please note that a valid payment method must be maintained on a paid tier account. You may be required to submit a support request as part of the payment method removal process.
Buckets can be created and deleted using the S3-compatible gateway, CLI, or Go library. For detailed information on how deleting a bucket works on Storj DCS, please see the appropriate section of this documentation:
Delete a bucket from the Satellite user interface
Delete a bucket using the Go library
Delete a bucket using the S3-compatible gateway
The easiest way to delete your data is to use the CLI. For detailed information on how to use the command for removing buckets on Storj DCS, please see the section of this documentation on how to delete a bucket from the command line.
We want all of our users to receive value when they choose the Storj DCS service for their storage needs, but it’s possible that a user may no longer need Storj DCS services. If a user wants to stop using an account and permanently delete the account, the user may do so only after following the steps outlined in the Billing Documentation to eliminate service usage.
The process to eliminate service usage starts with deleting all data from the service, including all objects and buckets. Next, all Access Grants should be deleted. Once this is done, the user should submit a ticket to remove all payment methods and delete the account.
For detailed information on how to close your account on Storj DCS, please see the Closing an Account section of this documentation.
The Storj DCS service is not designed to handle identity management for end users of applications that store data on the service. User authentication is expected to be handled by applications. Application developers may then make further design decisions related to use the authorization management functions of the service to enable secure and private sharing of data between users of an application or sharing data with a publicly available URL.