If you do update the docs (which would be great) it would nice nice to know which variables are options and which are required. Also if there are default values that would be helpful. I assume cache will default to memory if not set.

packet capture from proxy looks like things are returning 200 OK.

are you running the dockerized app? What server environment?

Yes it is dockerized app. This is part of the CDK to bring it up.

const proxyContainerName = createResourceName('dna-growthbook-proxy', RESOURCE_TYPE.EC2_INSTANCE, this.app.project)

    growthbookProxyTask.addContainer('DnaGrowthBookProxyContainer', {
      image: ecs.ContainerImage.fromRegistry('growthbook/proxy:latest'),
      containerName: proxyContainerName,
      essential: true,
      logging: ecs.LogDrivers.awsLogs({
        streamPrefix: 'blah-growthbook-proxy',
        logGroup,
      }),
      environment: proxyEnnvironment,
      secrets: proxySecrets,
      portMappings: [{
        containerPort: 3300,
      }],
    })

It all seems to be working.... I just don't know why we see some error in the logs.

Also seeing this:

2023-10-11T10:16:34.242-05:00	yarn run v1.22.19	Link 
2023-10-11T10:16:34.338-05:00	$ wsrun -p @growthbook/proxy -c start	Link 
2023-10-11T10:16:35.519-05:00	@growthbook/proxy	Link 
2023-10-11T10:16:35.519-05:00	| $ node dist/index.js	Link 
2023-10-11T10:16:36.627-05:00	| (node:70) [DEP0111] DeprecationWarning: Access to process.binding('http_parser') is deprecated.	Link 
2023-10-11T10:16:36.627-05:00	| (Use `node --trace-deprecation ...` to show where the warning was created)	Link 
2023-10-11T10:16:36.629-05:00	| GrowthBook proxy running over HTTP1.1, port 3300	Link 
2023-10-11T10:16:36.644-05:00	| /usr/local/src/app/packages/apps/proxy/dist/services/registrar/index.js:152	Link 
2023-10-11T10:16:36.702-05:00	| throw new Error("missing required context for polling for connections");	Link 
2023-10-11T10:16:36.702-05:00	| ^	Link 
2023-10-11T10:16:36.702-05:00	|	Link 
2023-10-11T10:16:36.703-05:00	| Error: missing required context for polling for connections	Link 
2023-10-11T10:16:36.703-05:00	| at /usr/local/src/app/packages/apps/proxy/dist/services/registrar/index.js:152:19	Link 
2023-10-11T10:16:36.703-05:00	| at Generator.next (<anonymous>)	Link 
2023-10-11T10:16:36.703-05:00	| at /usr/local/src/app/packages/apps/proxy/dist/services/registrar/index.js:8:71	Link 
2023-10-11T10:16:36.703-05:00	| at new Promise (<anonymous>)	Link 
2023-10-11T10:16:36.704-05:00	| at __awaiter (/usr/local/src/app/packages/apps/proxy/dist/services/registrar/index.js:4:12)	Link 
2023-10-11T10:16:36.705-05:00	| at initializeRegistrar (/usr/local/src/app/packages/apps/proxy/dist/services/registrar/index.js:130:42)	Link 
2023-10-11T10:16:36.705-05:00	| at /usr/local/src/app/packages/apps/proxy/dist/app.js:99:47	Link 
2023-10-11T10:16:36.705-05:00	| at Generator.next (<anonymous>)	Link 
2023-10-11T10:16:36.706-05:00	| at /usr/local/src/app/packages/apps/proxy/dist/app.js:31:71	Link 
2023-10-11T10:16:36.707-05:00	| at new Promise (<anonymous>)	Link 
2023-10-11T10:16:36.707-05:00	|	Link 
2023-10-11T10:16:36.707-05:00	| Node.js v18.18.0	Link 
2023-10-11T10:16:36.748-05:00	| error Command failed with exit code 1.	Link 
2023-10-11T10:16:36.748-05:00	| info Visit <https://yarnpkg.com/en/docs/cli/run> for documentation about this command.	Link 
2023-10-11T10:16:36.779-05:00	| `yarn start` failed with exit code 1	Link 
2023-10-11T10:16:36.818-05:00	error Command failed with exit code 1.	Link

which could also be consistent with the other polling error you're seeing above

Maybe this was just an issue when I first brought it up. Will play with it some more and see if it keeps happening.

Thanks for the tips

One thought: I did just ship a large refactor of the codebase a few days ago. If you want to pull the previous tagged release before this refactor, we could see if that helps https://github.com/growthbook/growthbook-proxy/releases/tag/v1.0.26

(of course that does complicate things a bit, harder to spin up)

When I do

env

in the shell the env variables are for sure set...

> env
AWS_EXECUTION_ENV=AWS_ECS_FARGATE
AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=/v2/credentials/...
HOSTNAME=ip-10-163-9-nnn.compute.internal
YARN_VERSION=1.22.19
PWD=/usr/local/src/app
ECS_CONTAINER_METADATA_URI_V4=<http://169.254.170.2/v4/xxx>
HOME=/root
LANG=C.UTF-8
GROWTHBOOK_API_HOST=<http://api.growthbook.local:3100>
CACHE_ENGINE=memory
ECS_AGENT_URI=<http://169.254.170.2/api/xxx>
TERM=xterm-256color
ENVIRONMENT=playground
ECS_CONTAINER_METADATA_URI=<http://169.254.170.2/v3/xxx>
SHLVL=1
SECRET_API_KEY=secret_readonly_xxx
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NODE_VERSION=18.18.0
_=/usr/bin/env

Just replaced some potentially sensitive info with

xxx

or

...

Is there any recommendations for when to scale up to more instances of proxies. Is it usually CPU, Memory, connections or something else that tend to exhaust first on a given instance?

That is what we just tested and seemed to work well.

I think we will add this too just in case:

scalableTaskCount.scaleOnCpuUtilization('CpuUtilizationScaling', {
    targetUtilizationPercent: 80,
})
scalableTaskCount.scaleOnMemoryUtilization('MemoryScaling', {
    target_utilization_percent=80,
})