This message was deleted.

What's the error you're getting? I see two potential issues: 1. You're not awaiting the

ensurePlugins

function. a. There will be a period of time where the plugins are installing and you won't be notified when it's done. 2. You're not returning and using the workspace reference. a. At the end of

ensurePlugins

add

return ws

It looks like you've correctly created the workspace, but you will probably need a reference that after creation. Something like:

const workspace = await ensurePlugins() // or rename it to something like `createWorkspace` or `loadWorkspace`

Another option: Use the static method

createOrSelectStack

from

LocalWorkspace

, then call

installPlugin

on the

stack.workspace

reference. See example here: https://github.com/pulumi/automation-api-examples/blob/80afd678f6adc51eb9f0279ca62408b7f1e4623c/nodejs/inlineProgram-ts/index.ts#L73

OK I’ll try that - thank you!

@most-lighter-95902 It really depends on the use-case of the app you're building. 1. Is the goal to provide a web service that can spin up pulumi resources? 2. Who are the users and what is the target usage? a. Are the users spinning up services directly or is this intended to be internal automation? 3. What is the target lifecycle of the resources? a. How long do they last? b. Who is responsible for them? A

LocalWorkspace

is a execution context containing a single Pulumi project, a program, and multiple stacks So it really depends on what you're spinning up. Is it a custom project each time (for example created from an

inline program

) or is it a static project spun up for many users? If it's custom, you'll want a new workspace for each project. If it's just spinning up the same project for many users, you can share a workspace and split up the ownership by stack. Also, I'm no pro, I'm still learning as well. Anyone else here, please feel free to jump in and correct me.

My use case is to create a project per client via REST API. Each client will have multiple stacks that spin up an EKS cluster along with a bunch of other services, but essentially my app would manage their infrastructure for them using the Pulumi Automation API.

Hmm it's hard to know where to put it without seeing the code. If you could put up a fork of the repo with your changes I may be able to glean more insight. If I were to set up a REST API where clients have managed infrastructure stacks, provided that the app code stays the same for each, I'd probably just have a shared reference. The other problem I see is: creating a workspace is asynchronous, so you'll have to be careful about where you create it and when you know it's ready. My initial thought would be

// types.ts
export interface System {
  workspace: LocalWorkspace
}

// workspace.ts
export interface Plugin {
  name: string
  version: string
}

export async function createWorkspace(plugins: Plugin[]) {
  const workspace = await LocalWorkspace.create({})
  // or if it's always the same plugins, just reference them directly here like in your first example
  for(const { name, version } of plugins) {
    await workspace.installPlugin(name, version)
  }
  return workspace
}

// router.ts
import express from 'express'
import asyncHandler from 'express-async-handler'

export default function createRouter({ workspace }: System) {
  const app = express.Router()
  app.get('/stacks', asyncHandler((req, res) => {
    const stacks = await workspace.listStacks()
    res.json(stacks)
  }))

  return app
}

// app.ts
import express from 'express'
import createRouter from './router'

async function main() {
  const defaultPlugins = [...]
  export default workspace = await createWorkspace(defaultPlugins)

  const app = express()

  app.use(createRouter({ workspace }))

  // app.listen, etc.
}

Thanks for the detailed example @thousands-hairdresser-72380 I’ll try that

@most-lighter-95902 lmk if you run into issues. it's definitely incomplete and will require additional configuration

Will do thanks!

@most-lighter-95902 Any luck?

Yes turns out I didn’t have Pulumi CLI installed in my server that was causing this error - once I added the script to my Dockerfile to install it, it works fine