Hey everyone, I was evaluating Glide Identity for a small project and just went through their sign-up flow. It was... interesting. Wanted to share my quick experience in case it helps other beginners like me.
The free tier setup was mostly straightforward, but I got stuck on the "Add Initial User" step using their CLI. My `config.yaml` looked like this, but it kept failing on the `email` field validation:
```yaml
user:
username: "alex_dev"
email: "alex@myproject-test.com"
role: "admin"
```
Turns out the email domain needed to be pre-verified in the dashboard first, which wasn't super clear from the error message. Also, the CLI command (`glide user add -f config.yaml`) required MFA from the get-go on my account, which is good, but I had to scramble to set up my authenticator app.
Anyone else try their onboarding? Is the CLI the main way they expect you to manage users, or is the web UI enough for basic use? Thinking about using this for IAM user lifecycle for a few AWS accounts.
> which wasn't super clear from the error message
Yeah, that's a common pain point with a lot of these cloud service CLIs. Good on you for figuring out the domain verification step.
For IAM user lifecycle across AWS accounts, their CLI-first approach might actually be a good fit once you're past the initial hurdles. You could wrap those `glide` commands in a Terraform `local-exec` or an Ansible playbook to automate the whole thing.
I'm curious, did you find the MFA setup annoying, or was it a decent experience once you had the app ready?
Infrastructure as code is the only way
The domain verification catch is a classic example of a vendor assuming you're operating in a corporate environment where all email domains are pre-vetted. It makes sense for security but absolutely torpedoes a quick personal trial if you're using a random test domain.
On your question about the CLI versus the UI, their documentation strongly implies the CLI is the primary interface for any real user management at scale. The UI is likely just a read-only dashboard or for manual one-off admin actions. If you're planning to automate IAM across AWS accounts, that CLI focus is actually a benefit; you can script the entire provisioning pipeline. Just factor in that MFA requirement for the CLI service account itself, which adds a layer of complexity to headless automation.
Show me the benchmarks
Ah, the classic "free tier" that requires you to jump through corporate-grade security hoops right out of the gate. The MFA scramble for a personal trial is such a lovely welcome.
You're asking if the CLI is the main way? That's the whole tell. They give you a UI, but the moment you try to do anything real, it's CLI or bust. It's a clear sign you're playing in a sandbox that's really meant for enterprise contracts where you'd have a dedicated ops person to script all this. For a few AWS accounts, you might spend more time wrestling with their automation philosophy than actually managing users.
—DW
Your whole cost calculation is missing the cloud bill overhead. Free tier? Great. MFA requirement from day one? That's a standard security posture you'd want.
But now you're talking about managing IAM across "a few AWS accounts." That's where your real cost sits. Every user you add in Glide likely translates to an IAM user or role in each AWS account, and that's where the bill grows. You're not just paying for Glide's free tier, you're paying for AWS resources *behind* it.
If you're serious, you need to model:
* Cost of SSO session durations (longer sessions = higher risk, but shorter = more frequent auth calls, potential API cost)
* Whether you'll need cross-account roles (AWS charges for AssumeRole calls)
* Data transfer if you're automating across regions
You're optimizing the wrong cost. The friction in sign-up is nothing compared to the friction of an unmanaged AWS bill six months from now. Script it with Terraform, sure, but script the cost tracking too.
show the math