Just for fun and giggles (and some learning experience) I wanted to install the Storj Gateway ST (single tenant). Just to understand what steps are involved and what to expect when it is up and running. If it works stable, it should also benefits Storj because I’m not longer relying on the hosted S3 Gateway.
Little heads-up: expect a lot of grammatical errors, I do use WORD for some basic grammatical corrections but still don’t like the use of AI. So if you are worried about misinterpretation or misinformation, just use the documentation provided by Storj.
Basically I followed the Storj documentation, unfortunately some things are a bit outdated and could use a review/update.
Documentation I used
- Installing Uplink CLI: https://storj.dev/learn/tutorials/quickstart-uplink-cli
- Create Access Grant in CLI: https://storj.dev/learn/tutorials/quickstart-uplink-cli/generate-access-grants-and-tokens/generate-a-token
- Installing Gateway ST: https://storj.dev/learn/self-host/gateway-st
Used system and specs
- Ubuntu 24.04.04 LTS (Virtual Machine)
- 2 vCores
- 4 GB ram
Installing Uplink CLI
Just follow the instructions, this part of the documentation is correct and works like a charm.
Create Access Grant in CLI
This part was a bit confusing. Partly my own fault (probably), because I tried to create an API Key in an existing project with a Encryption method: Automatic. For others it may be obvious but it took me a while to figure this one out why the API Key option was missing.
After I created a new project with Project Encryption: Self-Managed, I could finally create a new access with access type API Key.
I think that step 6, 7, 8 are not necessary when you install a Storj Gateway ST, but please let me know If I’m wrong (it works without those steps).
Installing Gateway ST
This part is pretty straight forward, just download and install the gateway and you’re ready for the configuring part.
When you want to choose your satellite, just enter the corresponding number. You don’t need to enter a node id or the full name of the satellite (FQDN), just the number 1, 2 or 3 will do.
Access name, I left it empty and just pressed ENTER
Enter you API key, this is the API key you just generated in the Storj web interface.
Enter your encryption passphrase, this is something you should generate on your own. Like mentioned in the documentation, keep it safe.
You can skip the documentation part about Using an Access Grant, because we are using an API key.
Starting your gateway
Now it is time to run the gateway, but I do think the documentation could use some extra information (although its mentioned at the end of the page). Default if you start run the gateway, it’s only locally accessible (127.0.0.1:7777). This is not very useful when you want to access the gateway from another system, like backup software running on another computer or server.
So instead of using the command gateway run lets use it with option gateway run --server.address 0.0.0.0:7777. This makes the service listen on all IP addresses. You could also bind it to a specific IP address.
When the gateway is running, it spit out your Access key and Secret key. You can use this to access the web interface or to login into your Storj project.
After you login into the web interface, you are able to create a bucket. In the bucket you are able to create folders or upload files.
Creating a service
Because I don’t want to run the gateway in a terminal or screen session, I created a service that starts when the server boots. Below a simple example that works well for me. Just adjust it accordingly for your situation.
Description=Storj Gateway ST
After=network.target
[Service]
ExecStart=/usr/local/bin/gateway run --server.address 0.0.0.0:7777
Restart=always
User=<user>
[Install]
WantedBy=multi-user.target
Making Storj Gateway ST redundant
If you want to host the gateway in a corporate environment, you would probably like some redundancy. In that case you install a second, third, etc server with the same steps. Keep in mind to skip the creation of a new API key, you have to use the exact same one you created earlier.
To prevent that every Gateway create its own unique Access and Secret key, you can pass you existing (or something you generated yourself) Access and Secret key as an commandline option. Something like this
gateway run --server.address 0.0.0.0:7777 --minio.access-key <access key> --minio.secret-key <secret key>
Because every Gateway has the same API key, Encryption Passphrase, Access key and Secret key, you can put the Gateway’s behind a load balancer. This way you ensure a high available setup and are able to share the load when you use multiple clients to access your S3 data.
Time for some testing and some observations.
I mainly use Storj as a personal (S3) backup target, backups are made from my Truenas Core (still need to migrate to Scale). Normally I use the pre configured Storj IX provider, but in this case you could use the Amazon S3 as provider and specify a custom endpoint URL and point it to your personal Gateway. Keep in mind that you have to explicitly tell to use http://, otherwise it assume you are using https://.
You could also use an S3 client like S3 Browser. Just connect to your Gateway and start uploading some files to the Storj network.
One problem I encountered (isn’t the first I encounter this one). Normally I use the S3 gateway that is hosted by Storj, this results in a few connections when you upload/download your data. But because you are hosting the S3 gateway yourself, you are connecting to (currently) a minimum of 54(?) SNO’s per part (my understanding, correct my if I’m wrong). This adds up very quickly. In my case, my consumer ISP router got overwhelmed by the +40.000 states which resulted in dropped connections. In the past I encountered this only with a lot of torrent traffic.
A workaround until I get this fixed, is to limit the maximum bandwidth. There are probably multiple ways to configure this, but I choose to limit the bandwidth on the virtual network in ESX. This means all transfers are a lot slower, but for now it is working and don’t experience any network drops.
Other thing to consider is the expansion factor. If you use the Storj hosted Gateway, the expansion factor is handled by Storj. Because you are hosting your own gateway, this time the expansion factor takes place locally. This means it generates a lot more internet traffic than “normally”.
2 cores and 4GB ram was enough to max out my 1GB fiber connection.
The Gateway doesn’t use a (self-signed) certificate. I don’t know if you could configure one or you should use a reverse proxy. Either way, for me personally it isn’t a issue. But in an corporate environment a certificate most definitely required.
Personal conclusion
Its easy to run your own S3 Gateway (ST) if the provided documentation is correct. Your data should be more secure because you manage the Encryption Passphrase, although I’m not that smart to audit the Gateway software/code for any backdoors. So do your own research if the data contains very sensitive information.
Just keep in mind that you are now directly connecting to SNO’s which results in a lot of connections. Make sure your network can handle all those connections.
Also a reminder about the expansion, this can add up really fast.
Questions for Storj (or the community)
- Is my interpretation and implementation correct or did I miss something important?
- Maybe something for in the future. Would it be possible to update the documentation with more recent screenshots that correspondent the current interface and mention the Self-Managed Project Encryption requirements?
- I’m a system administrator, definitely not a network engineer but stil a nerd at heart. I guess you guys are running some very nice (network) equipment and must have very good internet access to handle all this network traffic. Maybe something for after chapter 11, just a little sneakpeek how you handle this and maybe some peak numbers about network traffic (just a curious nerd asking).
If someone have questions about my installation, just ask. Please keep it topic related to keep things a bit organized.