Secrets Store General Availability

This is a valuable feature that has been a long time coming, thank you!

However, it’s missing a critical feature.

There NEEDS to be some form of local env secrets.

Being unable to use Play Solo for any experience that utilizes Secrets is such a huge workflow killer that I cannot adopt this feature. Making my game only function in Team Test is simply not an acceptable tradeoff. The blow to development velocity is huge. Developers can technically implement something like this themselves (assuming they use fully managed Rojo) but A. not everyone uses Rojo and B. if everyone is writing the same exact code, it’s something Roblox should have provided.

Edit: I’ve literally gone back to storing keys in plaintext because adopting Secrets makes it impossible to get anything done.


You’re right. This is one of the follow-ups that was not listed in the Next Steps section. Note that it won’t be the same set of Secrets - due to security reasons, we cannot let the experience private key to be available locally.

Yes, you can use Secrets within request headers. However, it’s not yet supported to use Secrets in the URL. We’re working on adding this capability, but there is a caveat that also applies for RequestAsync. Developers with write permissions can view server-side logs for HttpService, and these logs contain full URLs sent. Therefore my recommendation is to use Secrets in headers only, until we release URL filtering technique.


Not a big fan of the inconsistent casing, otherwise great work! We have been using it since the private beta in our game.

1 Like

I am gonna use this as my new password manager.

1 Like

I’m getting Can't find secret with given key error even when I’m putting in the secret name I setted on the creator page

1 Like

Are you running an instance in a local studio instance or in production? Secrets are only available for use in production and Team Create environments. If this is the case I recommend publishing your test place and trying it out on a live server. I also made a short script to specifically test out the problem you are having for use on a live server. Simply view the developer console in game to view its output.

local HttpService = game:GetService("HttpService")

local testKey = nil

local success, errorMessage = pcall(
		testKey = HttpService:GetSecret(SecretId)

if success then
	print(testKey) --this will print Secret(SecretId) if successful--


Since they aren’t printable by design, is it meant for API keys only?

When this was announced at RDC23, I was thinking this could be a good way to store classic Twitter Codes if for whatever reason putting the plain text in server scripts would not be enough.

I believe this is solely usable for keys used in HttpService requests. It would be really cool to have a way to store ANY codes/keys/etc. without having them be plaintext in scripts or hosted off-platform using some API.
Real quick: I just did a simple boolean comparison test to see if you could compare the value of a Secret with plaintext, even though it wasn’t part of the described features. Expectedly, it didn’t work as the value of the Secret will always be Secret(SecretID) until its decrypted by Roblox’s server’s for use in a HttpService request.


This was a much needed update and I’m so happy we finally have it.

It doesn’t seem to be getting the secret from the secret store?

This returns an error that says that the key couldnt be found.

I did put a secret in the secret store under that name though?

Do you run “Team Test” or just “Local Test”?
At the moment, only Team Test and production can fetch secrets from the Secret Store. This limitation is done to protect your secrets from being downloaded to your local computer. We are working on supporting locally defined secrets (my thinking, when we run the Local Test in Studio, we should just read secrets from some local file on your computer).

1 Like

Ah, I always use local test. I’ll make sure to use team test instead.

This is a great feature! Is this heading torwards being able to send requests to roblox to get stuff like how many players are in a place/experience, or seeing how many visits a place/experience has?

This has been fixed. See release notes: Release Notes for 619 | Documentation - Roblox Creator Hub

Fixes casing of Class.Secret:AddPrefix() and Class.Secret:AddSuffix(); you can now use them in UpperCamelCase as intended.

1 Like

I’m getting this error constantly during live servers, not sure what I’m doing as the key parameter in my GetSecret request is perfectly aligned with what I’ve set on the creator dashboard.

Just done a little debugging, turns out that calling GetSecret as soon as the server initialises causes the Can't find secret with given key error.

Just added in a small yield before the request is sent and it seems to be working fine now.

I experienced the same issue with GetSecret returning that the SecretKey did not exist, even though the key existed in the experience. I can confirm that yielding (Thanks for the suggestion) fixes the issue.

This is a bug and should be addressed - GetSecret is run synchronously, I expect it to yield until the secrets are retrieved from the secrets store and then check to see if the key exists; not (As a dev) needing to wait an arbitrary amount of time for new servers to spin up and hoping that the keys are retrieved in time.

Current behaviour is a compromise: game server startup is not blocked by Secrets (primarily, because most servers do not require secrets available at startup). However it is expected that Secrets are fetched in parallel with the rest of game server startup, and by the time it starts, Secrets are available. That said, I also consider “Secret not exist” as a problem - either a bug, or rare unfortunate event that should be happening super-rarely. Based on your feedback, this isn’t rare at all, and therefore must be looked into. One approach that I think is useful would be exposing RefreshSecrets functionality, that is synchronous, and waits until Secrets are received.


Thanks for looking into this! For additional context, I was using the Knit framework by sleitnick, and the GetSecret call was in the KnitInit portion of a server-side service. Putting the GetSecret call under the KnitStart portion of the code fixed it (a few hundred milliseconds after a new server starts up).