This message was deleted.
# getting-started
s
This message was deleted.
b
How should I tell the automation SDK to please use a locally managed service backend for this stack?
Run
pulumi login --local
before running the stack
w
Thanks! Is it intended that the automation API itself should be able to do this? It seems a bit awkward to build an automation API app that defines its own commands with an inline program and then preface it by saying “but first run `pulimi login --local`”… can this be done from the API?
it seems like it should be a workspace option or method, maybe?
b
it is a workspace option
Copy code
opts=LocalWorkspaceOptions(
        secrets_provider=SECRET_PROVIDER,
        work_dir=WORK_DIR,
        project_settings=ProjectSettings(
            name=PROJECT_NAME,
            runtime='python',
            backend=ProjectBackend(backend_url) # here
    )))
you can also set
PULUMI_BACKEND_URL
w
Oh I see, thank you!
this URL, would it make sense to make this just be
f"file://{WORK_DIR}/{STACK_NAME}"
? would that be a reasonable approach to managing pulumi service backend state in a git repo? (I’m aware there are some problems with this approach when it comes to eg. merge conflicts - that’s an issue for another day)
b
I would generally never recommend that, your mileage may vary.
w
When it comes to using a local service backend, what do you recommend?
b
the local backend is really for testing and trying things out, I’d recommend using an object store at a minimum
w
In the case of the minikube deployment target I’m working on here, it’s really always just going to be for local testing. Hmm, maybe I’ll just drop it in the user’s home directory then, since it doesn’t really need to be git managed, come to think of it. I definitely plan on using something like the s3 backend when it comes to my aws-ec2 target.
👍 1
Thanks!