Hi everyone! I'm still pretty new to LangSmith and trying to get my head around organizing things as my project grows. Right now, my biggest worry is that I'm going to accidentally evaluate something from my local staging environment and think it's from production. 😅
I saw you can add tags to traces. Would using something like `env:staging` and `env:production` be the right way to keep them separate? How are you all setting those tags automatically? I'm coming from a WordPress/Google Analytics background, where you'd just set a property ID, so this is a bit new for me. Any simple examples would be a lifesaver!
Yes, env tags are exactly right. That's the standard way to do it.
For setting them automatically, don't hardcode it in your app logic. Set it via an environment variable. In your app initialization, read something like `os.getenv("APP_ENV", "development")` and pass it to your LangSmith config as the `tags` parameter. It's one line.
The bigger risk is forgetting to filter by that tag when you run evaluations. Always check the dataset filter before you run anything.
Spot on about using an environment variable. That's the only way it's truly environment-aware.
I'd add that you can also apply tags at the project level in LangSmith's UI, which is a good backup if someone forgets to set the variable, but your way is the proper, automated one. Makes it part of the deployment process, not a manual step.
And you're so right about the filter. That's where the real accidents happen. I've seen a few panicked posts here that boiled down to a missed filter on a dataset. A scary moment, for sure.
Raise the signal, lower the noise.
Agreed on the environment variable. That's the way.
I'd push back a bit on "one line". In my experience, the config call often happens in a different module or is abstracted. The real fix is making sure the `APP_ENV` variable is *always* set in your deployment manifests. If it's missing, your CD pipeline should fail.
> The bigger risk is forgetting to filter
100%. The UI filter is sticky, but datasets aren't. You create a dataset from a production trace once and it's polluted forever. It's a one-way valve. I have a pre-commit hook that fails if a dataset query doesn't include an `env:` filter.
Proof in production.
Perfectly valid worry, and coming from that GA world, I get why the manual tagging feels a bit alien. The `env:staging`/`env:production` pattern is definitely the standard. For setting it automatically, the environment variable method everyone's mentioning is key, but let me give you a concrete example from my setup, because the exact place you set it in LangChain can be tricky.
I use a small config module that runs early. It looks something like this:
```python
import os
from langsmith import Client
client = Client(
api_key=os.getenv('LANGCHAIN_API_KEY'),
tags=[f"env:{os.getenv('APP_ENV', 'development')}"],
)
```
The crucial bit is making sure that `Client` (or whatever your tracer is) is configured globally *once* with those tags, so every trace inherits them. If you're initializing things in different places, that's where the leak happens. And yeah, `APP_ENV` should be set in your docker-compose, k8s config, or serverless environment - never in the code itself.
What backend framework are you using? Sometimes the pattern changes a little depending on if it's FastAPI, Django, or a plain script.
Keep it simple.
Yes, the env tags are the right way. They're simple and work.
But that last part about setting a property ID... I get that. Coming from tools where you just plug in a different ID, this feels like extra setup. The hard part isn't the tag itself, it's making sure it actually gets set every single time. If your environment variable isn't loaded right, you get no tag at all, which is worse than a wrong one.