Blueprint deploy page stopped working

i am on my third day trying to deploy Temporal to Render and have tried wiping my Render instance clean by manually deleting each resource one by one. Now when I try to deploy my blueprint this happens:

In other words, it grays out when I click Apply, and then nothing. If there was an error, nothing is shown either in UI or in the dev console (which only says “Hi there! You’re looking at Render version 4ae5dc684.”.

What is going wrong? How do I debug an unresponsive UI?

i gave up, went and did other stuff, came back 10 mins later and now found two instances of my Blueprint being deployed

including a new “unknown” state that I don’t reckognize. this feels extremely unreliable and flaky - what am i doing wrong here please? is this normal for Render or is my thing way too resource intensive?

Hi @swyx, we’re planning to improve error messaging and logging for Blueprint instances.

Most of the team is out on a well-deserved break this week so responses will be delayed; I’ll follow up over DM.

Here’s a sample Temporal setup from one of our customers:

services:
  - type: pserv
    name: temporal-history
    autoDeploy: false
    plan: Standard
    env: docker
    dockerfilePath: ./temporal/server/Dockerfile
    dockerContext: ./temporal/server
    envVars:
      - key: STATSD_ENDPOINT
        value: temporal-datadog-agent:8125
      - key: SERVICES
        value: history
      - key: DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: VISIBILITY_DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: DYNAMIC_CONFIG_FILE_PATH
        value: /etc/temporal/dynamicconfig/development.yaml
      - key: POSTGRES_USER
        fromDatabase:
          name: temporal
          property: user
      - key: POSTGRES_PWD
        fromDatabase:
          name: temporal
          property: password
      - key: POSTGRES_SEEDS
        fromDatabase:
          name: temporal
          property: host
  - type: pserv
    autoDeploy: false
    name: temporal-frontend
    env: docker
    dockerfilePath: ./temporal/server/Dockerfile
    dockerContext: ./temporal/server
    envVars:
      - key: STATSD_ENDPOINT
        value: temporal-datadog-agent:8125
      - key: SERVICES
        value: frontend
      - key: DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: VISIBILITY_DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: DYNAMIC_CONFIG_FILE_PATH
        value: /etc/temporal/dynamicconfig/development.yaml
      - key: POSTGRES_USER
        fromDatabase:
          name: temporal
          property: user
      - key: POSTGRES_PWD
        fromDatabase:
          name: temporal
          property: password
      - key: POSTGRES_SEEDS
        fromDatabase:
          name: temporal
          property: host
  - type: pserv
    autoDeploy: false
    name: temporal-matching
    env: docker
    dockerfilePath: ./temporal/server/Dockerfile
    dockerContext: ./temporal/server
    envVars:
      - key: STATSD_ENDPOINT
        value: temporal-datadog-agent:8125
      - key: SERVICES
        value: matching
      - key: DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: VISIBILITY_DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: DYNAMIC_CONFIG_FILE_PATH
        value: /etc/temporal/dynamicconfig/development.yaml
      - key: POSTGRES_USER
        fromDatabase:
          name: temporal
          property: user
      - key: POSTGRES_PWD
        fromDatabase:
          name: temporal
          property: password
      - key: POSTGRES_SEEDS
        fromDatabase:
          name: temporal
          property: host
  - type: pserv
    autoDeploy: false
    name: temporal-srv-worker
    env: docker
    dockerfilePath: ./temporal/server/Dockerfile
    dockerContext: ./temporal/server
    envVars:
      - key: STATSD_ENDPOINT
        value: temporal-datadog-agent:8125
      - key: PUBLIC_FRONTEND_ADDRESS
        value: temporal-frontend:7233
      - key: SERVICES
        value: worker
      - key: DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: VISIBILITY_DBNAME
        fromDatabase:
          name: temporal
          property: database
      - key: DYNAMIC_CONFIG_FILE_PATH
        value: /etc/temporal/dynamicconfig/development.yaml
      - key: POSTGRES_USER
        fromDatabase:
          name: temporal
          property: user
      - key: POSTGRES_PWD
        fromDatabase:
          name: temporal
          property: password
      - key: POSTGRES_SEEDS
        fromDatabase:
          name: temporal
          property: host
  - type: pserv
    autoDeploy: false
    name: temporal-datadog-agent
    env: docker
    dockerfilePath: ./temporal/datadog-agent/Dockerfile
    dockerContext: ./temporal/datadog-agent
    envVars:
      - key: DD_API_KEY
        sync: false
  - type: web
    autoDeploy: false
    name: temporal-ui
    env: docker
    dockerfilePath: ./temporal/ui/Dockerfile
    dockerContext: ./temporal/ui
    envVars:
      - key: TEMPORAL_GRPC_ENDPOINT
        value: temporal-frontend:7233
      - key: TEMPORAL_CONFIG_PATH
        value: /etc/secrets/config.yml
  - type: worker
    autoDeploy: false
    name: temporal-admin-tools
    env: docker
    dockerfilePath: ./temporal/admin-tools/Dockerfile
    dockerContext: ./temporal/admin-tools
    envVars:
      - key: TEMPORAL_CLI_ADDRESS
        value: temporal-frontend:7233

databases:
  - name: temporal
    databaseName: temporal
    user: temporal
    plan: standard

replying to say i note and appreciate the replies, went without saying that of course i didnt expect a response during the holiday break, but i shouldve gone ahead and said that instead of leaving it implicit :slight_smile:

happy new year and may it be a :rocket: year for you folks

user feedback - there appears to be no way to mass delete fields of services when blueprint deploys go bad like this.

rather than go into the settings and typign out sudo delete service by service, looks like i have to just delete my account. i’ll be back, but just reckon that tighter syncing of state is impt if i’m trying to do blueprint development (and get things wrong, regardless of whose fault it is)