https://prefect.io logo
Join Slack
Powered by
<@ULVA73B9P> I see that in the Prefect Docker work...
# ask-community
v
@Marvin I see that in the Prefect Docker work pool, when a container is started, there is an environment variable DT_PYTHON_OPTIONS which contains a nativeLibPath pointing to liboneagentpython.so at some path (e.g., /app/gtdt). I have not set this variable myself. Who is setting it, and why? I am using an EPV CLI (inside the flow) that runs on a process‑type worker on a VSI machine. I am also running the Docker worker on the same VSI machine, but the EPV flows fail with error code PDKTC511E. I suspect the failure is because of this path: EPV is also looking for the same *.so file, and it works with the VSI process‑pool setup because the library path there points to the correct location (/lib64), whereas in the Docker work‑pool container it points to /app/gtdt. Can you please tell me how to resolve this?
m
✅ thought for 158.5 seconds
DT_PYTHON_OPTIONS
is not something Prefect normally invents on its own. Most likely, it is being injected by your environment/image/runtime and then passed into the Docker job configuration that Prefect uses for the container. In your case, that strongly suggests a Dynatrace/OneAgent-style instrumentation variable, since 
nativeLibPath=...liboneagentpython.so
is exactly that kind of setting. What’s probably happening - On the VSI process worker, your EPV CLI sees a library path that works, like 
/lib64/...
- On the Docker worker, the flow runs inside a container, and 
DT_PYTHON_OPTIONS
points to 
/app/gtdt/...
- EPV appears to also inspect/use that setting, so inside the container it tries to use the wrong 
.so
location and fails with 
PDKTC511E
So the root issue is likely environment inheritance / injection, not Prefect-specific EPV logic. Who is setting it? Usually one of these: 1. A host-level agent/injector on the VSI 2. Your Docker image via 
ENV DT_PYTHON_OPTIONS=...
3. The Prefect work pool base job template or deployment 
job_variables.env
4. A container runtime wrapper / entrypoint script Prefect’s Docker worker does set an 
environment
dict for the container, but 
DT_PYTHON_OPTIONS
is not a standard Prefect variable. What to check first 1. Inspect the work pool:
Copy code
bash
prefect work-pool inspect <your-pool-name> --output json
Look in: - 
base_job_template.job_configuration.env
2. Inspect the deployment:
Copy code
bash
prefect deployment inspect "<flow-name>/<deployment-name>"
3. Inspect the image:
Copy code
bash
docker inspect <your-image> | jq '.[0].Config.Env'
4. Check the worker host:
Copy code
bash
env | grep DT_PYTHON_OPTIONS
If it exists on the host or image, that’s your source. How to resolve it You have a few options: Option 1: Explicitly unset or override 
DT_PYTHON_OPTIONS
for the Docker job If EPV should not see that variable in the container, remove it from the container env. For a deployment, set 
job_variables.env
so it overrides the inherited value. Example idea:
Copy code
python
my_flow.from_source(
    source=".",
    entrypoint="flows.py:my_flow",
).deploy(
    name="my-deployment",
    work_pool_name="docker-pool",
    job_variables={
        "env": {
            "DT_PYTHON_OPTIONS": ""
        }
    }
)
If empty string is not enough for EPV, you may need to ensure it is absent entirely by removing it from the work pool base job template instead. Option 2: Set it to the correct in-container path If EPV does need the variable, point it to the correct library path inside the container, e.g. 
/lib64/...
if that path exists in the image.
Copy code
python
job_variables={
    "env": {
        "DT_PYTHON_OPTIONS": "nativeLibPath=/lib64/liboneagentpython.so"
    }
}
Only do this if that path is actually valid inside the container. Option 3: Build/fix the Docker image so the expected library exists at the path If 
/app/gtdt/...
is expected by your org’s instrumentation, then the image may need the agent files mounted or baked in correctly. Option 4: Disable the monitoring injection for this container/workload If this is Dynatrace/OneAgent auto-injection, your infra team may need to exclude these Prefect-run containers or adjust injection behavior. My recommendation Given your description, I’d try this order: 1. Find where 
DT_PYTHON_OPTIONS
is coming from 2. For the Docker deployment, override or remove it 3. If EPV requires it, set it explicitly to the correct in-container path 4. If the variable keeps reappearing, investigate Dynatrace/agent injection on the VSI or in the image Important detail A path that works on the VSI host does not automatically work in the Docker container. 
/lib64
on the host and 
/lib64
in the container are different filesystems unless you deliberately mount/share them. Useful commands
Copy code
bash
prefect work-pool inspect <pool-name> --output json
```bash
prefect deployment inspect "<flow-name>/<deployment-name>"
Copy code
```bash
docker inspect <image-name>
Copy code
bash
docker exec <container-id> env | grep DT_PYTHON_OPTIONS
Docs: - Work pools - Deployments If you want, I can help you identify the exact field to change if you paste: - your Docker work pool 
base_job_template
- and/or the deployment 
job_variables
/ 
prefect.yaml
snippet
v
@Marvin docker wok pool the container exit with 1 but worker did not send the event back to server and flow stuck in running state.
m
✅ thought for 161.0 seconds
If a Docker work pool container exits with code 
1
, the worker should mark the flow run as 
Crashed
/ failed infrastructure, not leave it in 
Running
. So if it stays 
Running
, the usual issue is not the exit code itself — it’s that the worker or the flow process could not report the terminal state back to the API. Most likely causes: * the container lost connectivity to the Prefect API * the worker lost connectivity to the Prefect API * the worker crashed or hung after the container exited * the container was removed too quickly (
auto_remove
) before the worker finished inspecting it * Docker daemon/API became unresponsive while the worker was waiting on the container What Prefect does internally: * Docker worker reads container exit code * if non-zero, it proposes a crashed state to the API * if that API update never succeeds, the run can remain stuck in 
Running
A few concrete things to check: 1. Worker logs Look for errors like: * 
Failed to update state of flow run
* Docker API errors / timeouts * container removed before wait completed * API/network connection errors Run worker with debug logging:
Copy code
bash
export PREFECT_LOGGING_LEVEL=DEBUG
prefect worker start --pool <your-pool>
2. Flow container logs Check whether the container can reach your Prefect API URL. This is a very common root cause. In particular verify: * 
PREFECT_API_URL
is correct inside the container * if self-hosted, don’t rely on 
localhost
unless the API is actually inside that same container * on Linux Docker setups, 
host.docker.internal
may need special handling depending on your network setup Related issue about container/API connectivity: Docker agent with server tasks stuck submitted: host.docker.internal connection error 3. Disable auto-removal temporarily If your pool/job config removes containers immediately, disable that so you can inspect the finished container:
Copy code
yaml
job_variables:
  auto_remove: false
  stream_output: true
4. Increase Docker client timeout If Docker is slow/unresponsive:
Copy code
bash
export DOCKER_CLIENT_TIMEOUT=600
5. Enable zombie/unresponsive run detection Prefect recommends heartbeat-based detection for runs that get stuck in 
Running
when infrastructure disappears or cannot report back. Docs: Detect zombie flows You can also enable flow heartbeats with:
Copy code
bash
export PREFECT_FLOWS_HEARTBEAT_FREQUENCY=180
Then set that in the worker/container environment too. Important note: This symptom is often a network/reporting problem, not a Docker execution problem. The container may have exited correctly with 
1
, but if neither the flow process nor the worker can successfully call the API afterward, the run can remain 
Running
. If you want, I can help you narrow it down quickly if you share: * your Prefect version * whether this is Prefect Cloud or self-hosted server * the worker logs around the time the container exited * whether 
auto_remove
is enabled * the container/job config for 
PREFECT_API_URL
v
@Marvin docker container still exist on same machine (not removed) and worker and container are on same machine. I can see same worker can run flows completely now. if there was a network issue will worker not try again after sometime ?
m
✅ thought for 149.1 seconds
Short answer: yes, it retries a little, but not indefinitely. In Prefect 3.x, the worker/client does have automatic HTTP retries for transient API failures, but only during that one state-update attempt. If those retries are exhausted, the worker logs the failure and moves on. It does not keep coming back later to reconcile that old run state. So for your case: * container exits with 
1
* worker tries to report terminal/crashed state * if API/network call fails at that moment, Prefect retries for a short window * if it still fails, that update is dropped * the flow run can remain stuck in 
Running
even though the worker is healthy afterward and can run new flows So a later return to normal connectivity does not automatically fix that already-stuck run. Details: * default client retries are about 
5
retries * backoff is exponential, roughly over about a minute total * after that, worker logs something like 
Failed to update state of flow run ...
* there is no background reconciliation loop that later says “oh, that container already exited, let me mark it crashed now” This matches what you observed: * same worker can run flows successfully now * old run is still stuck * container still exists => that strongly suggests the failure happened during the terminal state report window, not that the worker is permanently broken What I’d check next: 1. Worker logs around container exit time Search for:
Copy code
text
Failed to update state of flow run
httpx
ConnectError
ReadTimeout
LocalProtocolError
RemoteProtocolError
2. Container logs If the flow process inside the container also failed to talk to the API near shutdown, that can contribute too. 3. Prefect version There have been various client/network edge cases over time, so if you are not on a recent 3.x, upgrading is worth considering. 4. Enable zombie detection / heartbeats This is the protection against exactly these “run stuck in Running” cases: Detect zombie flows If you want, paste: * your Prefect version * the worker log lines from just before/after the container exited * whether you use Cloud or self-hosted API and I can help pinpoint whether it was an API retry exhaustion, Docker wait issue, or something else.
v
@Marvin I am getting redis connection error in cancellation listener and only getting this error while use haproxy in front of redis and not getting for single redis instance direct connection. prefect redis version is 0.2.10 . what is this happening
m
✅ thought for 148.6 seconds
Most likely: HAProxy is breaking the Redis connection semantics that Prefect’s cancellation listener relies on. With 
prefect-redis==0.2.10
, the cancellation/cleanup listener uses Redis in a way that is more sensitive than simple direct commands. When you connect straight to a single Redis instance, the connection stays consistent and everything works. When you put HAProxy in front, the listener can hit connection/proxy behavior that does not affect simpler request/response usage. What’s probably happening: 1. Long-lived Redis connection behavior The cancellation listener uses long-lived Redis client connections and coordination patterns that are sensitive to disconnects/resets. HAProxy can interrupt or recycle these connections because of: * idle timeout * server timeout * health-check-driven backend changes * TCP connection reuse behavior So even if normal Redis calls work, this listener can fail because it depends on a stable connection over time. 2. Transaction / connection-affinity issues 
prefect-redis
cleanup/cancellation internals use Redis transaction-style coordination (
WATCH
/ 
MULTI
patterns). Those patterns are connection-specific. If a proxy causes the effective backend connection/context to change unexpectedly, Redis transaction state is lost or invalidated. That’s why: * direct single Redis => stable, works * HAProxy in front => intermittent connection/protocol errors in listener 3. Blocking / listener-style operations are more proxy-sensitive Listener/consumer loops often use blocking or near-blocking reads/polls. These are much more likely than ordinary Redis 
GET/SET
traffic to expose HAProxy timeout problems. So this is not surprising if you only see it in the cancellation listener. What to check in HAProxy first: * increase timeouts substantially
Copy code
text
timeout connect 10s
timeout client  300s
timeout server  300s
timeout tunnel  300s
timeout client-fin 300s
timeout server-fin 300s
* if you use health checks / balancing, make sure HAProxy is not bouncing these long-lived Redis connections between backends * if this is actually multiple Redis backends behind HAProxy, that is a big red flag unless you have a very specific Redis-aware architecture * prefer pure TCP mode, not anything Redis-protocol-aware unless intentionally configured Important question: Are you using HAProxy in front of a single Redis server, or load balancing across multiple Redis servers? Because: * single Redis behind HAProxy => usually a timeout / connection reset / keepalive issue * multiple Redis servers behind HAProxy => very likely incompatible with the listener’s transaction/connection assumptions Best practical recommendation: For Prefect cancellation/cleanup Redis, connect directly to Redis if possible instead of through HAProxy, especially with 
prefect-redis 0.2.10
. If you must keep HAProxy: * use TCP passthrough * pin to a single backend * increase idle/server/client timeouts * avoid balancing across multiple standalone Redis instances for this workload If you want, paste: * the exact Redis error from the cancellation listener * your HAProxy backend/frontend config * whether HAProxy points to one Redis or several and I can tell you which of those failure modes you’re hitting.
v
@Marvin this is just a warning . can i ignore this or will it create functional issue?
m
✅ thought for 13.6 seconds
I would not blindly ignore it. If the warning is coming from the cancellation listener, the risk is usually functional, not just cosmetic. The main impact would be: * cancelled flow runs may not be cancelled promptly * cancellation signals may be delayed or missed * cleanup/worker coordination may be unreliable * in edge cases, runs can continue executing after you requested cancellation If everything else is healthy, you might not notice it often — but when you do need cancellation, it may fail or be flaky. So the practical answer is: If you never rely on cancellation and this warning is rare/intermittent, it may be tolerable temporarily. If you rely on cancelling runs, enforcing SLAs, or cleaning up stuck work reliably, do not ignore it. A good way to judge severity: Safe-ish to tolerate temporarily * warning is infrequent * cancellations still work in testing * no stuck runs / no delayed stop behavior Not safe to ignore * warnings appear repeatedly * cancellations are delayed or don’t happen * workers/runs sometimes remain active after cancel request * cleanup listener reconnects constantly Quick test I’d recommend: 1. start a long-running flow 2. cancel it from Prefect 3. verify the worker receives cancellation quickly 4. repeat several times through HAProxy If cancellation is inconsistent, then this warning is definitely a real functional issue. So: temporary ignore? maybe. Permanent ignore? no. If you share the exact warning text, I can tell you how serious it is.
v
@Marvin create. a base job configuration file for prefect ecs worker where cred part should be null as ecs worker is also running in same ecs cluster and it should start flows in same cluster.
m
✅ thought for 107.7 seconds
Yes — here’s a base job configuration example for an ECS work pool where: * the worker itself runs in ECS * flow-run tasks should launch in the same ECS cluster * no explicit AWS credentials are provided, so boto/AWS auth comes from the ECS task role attached to the worker A couple of notes first: * In Prefect 3.x, you generally configure this as a work pool base job template * You should omit 
aws_credentials
rather than trying to force a fake value * You set the 
cluster
explicitly to the cluster name/ARN you want the worker to submit tasks into Example base job template:
Copy code
json
{
  "job_configuration": {
    "region": "{{ region }}",
    "cluster": "{{ cluster }}",
    "launch_type": "{{ launch_type }}",
    "family": "{{ family }}",
    "image": "{{ image }}",
    "cpu": "{{ cpu }}",
    "memory": "{{ memory }}",
    "execution_role_arn": "{{ execution_role_arn }}",
    "task_role_arn": "{{ task_role_arn }}",
    "configure_cloudwatch_logs": true,
    "cloudwatch_logs_options": {
      "awslogs-region": "{{ region }}",
      "awslogs-group": "{{ cloudwatch_logs_group }}",
      "awslogs-stream-prefix": "prefect"
    },
    "env": "{{ env }}",
    "command": "{{ command }}",
    "stream_output": true,
    "vpc_id": "{{ vpc_id }}",
    "network_configuration": "{{ network_configuration }}"
  },
  "variables": {
    "type": "object",
    "properties": {
      "region": {
        "type": "string",
        "title": "AWS Region",
        "default": "us-east-1"
      },
      "cluster": {
        "type": "string",
        "title": "ECS Cluster",
        "default": "your-ecs-cluster-name"
      },
      "launch_type": {
        "type": "string",
        "title": "Launch Type",
        "default": "FARGATE"
      },
      "family": {
        "type": "string",
        "title": "Task Definition Family",
        "default": "prefect-flow"
      },
      "image": {
        "type": "string",
        "title": "Image",
        "default": "your-image:latest"
      },
      "cpu": {
        "type": "string",
        "title": "CPU",
        "default": "1024"
      },
      "memory": {
        "type": "string",
        "title": "Memory",
        "default": "2048"
      },
      "execution_role_arn": {
        "type": "string",
        "title": "Execution Role ARN",
        "default": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
      },
      "task_role_arn": {
        "type": "string",
        "title": "Task Role ARN",
        "default": "arn:aws:iam::123456789012:role/prefectFlowTaskRole"
      },
      "cloudwatch_logs_group": {
        "type": "string",
        "title": "CloudWatch Logs Group",
        "default": "/ecs/prefect-flows"
      },
      "env": {
        "type": "object",
        "title": "Environment Variables",
        "default": {}
      },
      "command": {
        "type": "string",
        "title": "Command",
        "default": "python -m prefect.engine"
      },
      "vpc_id": {
        "type": "string",
        "title": "VPC ID",
        "default": ""
      },
      "network_configuration": {
        "type": "object",
        "title": "Network Configuration",
        "default": {
          "awsvpcConfiguration": {
            "assignPublicIp": "ENABLED",
            "subnets": [
              "subnet-xxxxxxxx"
            ],
            "securityGroups": [
              "sg-xxxxxxxx"
            ]
          }
        }
      }
    }
  }
}
Important part for your requirement: there is no 
aws_credentials
section at all That means Prefect will use the normal AWS credential chain, and because your worker is running as an ECS task, it will use the task role credentials automatically. If you want the worker to submit runs into the same cluster, set:
Copy code
json
"cluster": "{{ cluster }}"
and give 
cluster
the default value of your ECS cluster name or ARN. If you want something a bit more practical/minimal, here is a cleaner version you can start from: ```json {
"job_configuration": { "region": "{{ region }}", "cluster": "{{ cluster }}", "launch_type": "FARGATE", "image": "{{ image }}", "cpu": "{{ cpu }}", "memory": "{{ memory }}", "execution_role_arn": "{{ execution_role_arn }}", "task_role_arn": "{{ task_role_arn }}", "env": "{{ env }}", "configure_cloudwatch_logs": true, "cloudwatch_logs_options": { "awslogs-region": "{{ region }}", "awslogs-group": "{{ cloudwatch_logs_group }}", "awslogs-stream-prefix": "prefect" }, "network_configuration": { "awsvpcConfiguration": { "assignPublicIp": "ENABLED", "subnets": "{{ subnets }}", "securityGroups": "{{ security_groups }}" } }, "stream_output": true }, "variables": { "type": "object", "properties": { "region": { "type": "string", "default": "us-east-1" }, "cluster": { "type": "string", "default": "your-ecs-cluster-name" }, "image": { "type": "string", "default": "your-image:latest" }, "cpu": { "type": "string", "default": "1024" }, "memory": { "type": "string", "default": "2048" }, "execution_role_arn": { "type": "string", "default": "arnawsiam:123456789012role/ecsTaskExecutionRole" }, "task_role_arn": { "type": "string", "default": "arnawsiam:123456789012role/prefectFlowTaskRole" }, "cloudwatch_logs_group": { "type": "string", "default": "/ecs/prefect-flows" }, "env": { "type": "object", "default": {} }, "subnets": { "type": "array", "items": { "type": "string" }, "default": [ "subnet-xxxxxxxx" ] }, "security_groups": { "type": "array", "items": { "type": "string" }, "default": [ "sg-xxxxxxxx" ] } } } } ``` A few important clarifications: * 
execution_role_arn
is for ECS task startup things like pulling from ECR / pushing logs * 
task_role_arn
is the IAM role the flow run container uses * the worker task role must itself have permission to call ECS APIs like 
RunTask
, 
DescribeTasks
, 
RegisterTaskDefinition
, etc. * if your flow image is in ECR and logs go to CloudWatch, those roles must allow that too Also, one correction to avoid an old 2.x pattern: if you want to deploy in Prefect 3.x, use 
flow.from_source(...).deploy(...)
or 
prefect deploy
, not 
Deployment.build_from_flow()
. Docs: * Prefect AWS ECS worker docs * Work pools If you want, I can also give you: * a full base job template exactly matching the current ECS worker schema, or * a 
prefect work-pool create --type ecs
+ update JSON workflow, or * a Terraform-ready version of this template.
v
@Marvin give me the recent bug fixes after prefect version 3.6.27
m
✅ thought for 16.6 seconds
Here are the recent bug fixes after Prefect 
3.6.27
 that I can confirm from the latest release notes I have access to. These are from the newer release notes currently available, and include fixes after `3.6.27`: Bug fixes * Fix deploy init field parsing — #22183 * Fix 
parse_obj_as()
crash with 
StopIteration
on empty dict — #22188 * Fix prompt to save new deployments into an existing 
prefect.yaml
— #22195 * Filter stdlib paths from 
PYTHONPATH
to prevent subprocess CLI breakage — #22179 * Recover perpetual services after Redis disruption — #22213 A few especially relevant ones based on your earlier questions: * Recover perpetual services after Redis disruption — likely relevant if you were seeing Redis/cancellation-listener warnings * deploy/prefect.yaml fixes — relevant if you use 
prefect deploy
Full latest changelog: Prefect 3.7.3...3.7.4 changelog If you want, I can also give you one of these: * all bug fixes between 
3.6.27
and latest, grouped by version * just Redis/worker/cancellation-related fixes after 
3.6.27
 * whether upgrading from 
3.6.27
would likely help your specific issue
v
@Marvin I am able to bring up prefect costomer managed server and server is coming up but after load it says" you don't have access to any workspace , contact admin" ? how do i get this workspace access. I am running the prefect server on-prem
m
✅ thought for 161.3 seconds
If you are running Prefect Server on-prem/self-hosted, you should not need Prefect Cloud workspace access. That message usually means the UI/browser is pointed at Prefect Cloud or is using a Cloud login/session, instead of talking directly to your self-hosted API/UI. What to do: 1. Make sure you are opening the self-hosted UI URL For self-hosted Prefect Server, the UI is typically served from your own server, for example:
Copy code
text
http://<your-host>:4200
and the API is typically:
Copy code
text
http://<your-host>:4200/api
Check health:
Copy code
bash
curl http://<your-host>:4200/api/health
2. Point your client to your self-hosted API Set:
Copy code
bash
prefect config set PREFECT_API_URL="http://<your-host>:4200/api"
Then confirm:
Copy code
bash
prefect config view
3. Do not log into Prefect Cloud for this server If your browser has an existing Prefect Cloud session, the UI can get confused and show Cloud-style workspace messaging. Try: * open the self-hosted UI in an incognito/private window * log out of Prefect Cloud * clear site storage/cookies for Prefect UI * then reopen your on-prem URL directly 4. Check reverse proxy / ingress config If you have nginx/ingress in front of Prefect, make sure it is not rewriting requests to Prefect Cloud endpoints and that the UI can access: * 
/api/health
* 
/ui-settings
For example:
Copy code
bash
curl http://<your-host>:4200/ui-settings
You should get JSON for your local server settings. Important point Self-hosted Prefect Server does not use Cloud workspaces the same way Prefect Cloud does. There is no separate “grant me workspace access” step you need to perform for an on-prem install. So the fix is usually: use the self-hosted UI/API directly, not a Cloud URL/session Useful docs: * Self-host Prefect * Prefect server concepts If you want, send me: * the exact URL you are opening in the browser * your 
PREFECT_API_URL
* whether you put a reverse proxy in front of Prefect and I can tell you exactly what is misconfigured.
v
@Marvin it's not open sourced one , it is enterprise version prefect
m
✅ thought for 10.6 seconds
Ah — if this is Prefect Enterprise / customer-managed, then that changes things. In Enterprise customer-managed, the workspace/access model does apply, so that message means your logged-in user is authenticated but is not assigned to any workspace in that Enterprise installation. What this means: * your Enterprise server is up * auth is working * but your user has not been granted membership to a workspace, or no workspace has been created/assigned yet How you get access: * an Enterprise admin for that installation needs to: * create a workspace if none exists * assign your user to that workspace * ensure the right org / role mapping is configured if using SSO/OIDC/SAML Common causes: * initial Enterprise bootstrap created the platform but no user-to-workspace assignment was completed * SSO is enabled, but group/role mapping is not mapping your identity to any workspace * you signed in with the wrong identity/provider * default workspace provisioning step was skipped during setup Because this is not the open-source self-hosted server, this is not something you fix with 
PREFECT_API_URL
alone — it is an Enterprise RBAC/workspace provisioning issue. What to check with your Enterprise admin: * Is there at least one workspace created? * Is your user assigned to a workspace? * If using SSO, are the IdP groups/claims mapped correctly? * Are you logging in with the expected email/identity? * Was initial Enterprise setup fully completed? I can’t provision or assign the workspace for you, but the right path for Enterprise-specific setup/access issues is: Prefect contact If you want, I can help you narrow it down before you reach out — for example, if you tell me: * are you using local auth or SSO? * is this the first user logging in after install? * do other users see the same message? I can help you figure out whether it’s likely: * missing workspace creation * missing user assignment * broken SSO group mapping * wrong login identity
v
@Marvin I only setup the prefect enterprise server, how can to admin in this case? how to decide admin and how to do "default workspace provisioning step" while bringing up prefect enterprise server
m
✅ thought for 14.3 seconds
For Prefect Enterprise / customer-managed, the initial admin user and workspace provisioning are not self-serve in the same way as open-source Prefect Server. Those are part of the Enterprise setup/configuration process. So the honest answer is: I can explain what the issue means, but I can’t reliably tell you a supported bootstrap command or secret “make myself admin” procedure unless it’s documented for your specific Enterprise deployment package — and I don’t have a verified public doc for that flow here. What your current state likely means: * Enterprise UI is up * auth backend is enabled * you authenticated successfully * but no workspace membership exists for your user yet * and possibly no initial admin/workspace bootstrap was completed For Enterprise, the right path is: Prefect contact That is the proper route for: * initial admin bootstrap * first workspace provisioning * SSO / RBAC mapping * customer-managed Enterprise installation setup questions A few practical notes in the meantime: “How is admin decided?” Usually in enterprise systems, one of these is used: * a bootstrap admin configured during installation * an identity/email configured as initial admin * SSO group/claim mapping to an admin role * a setup job/script run during deployment But for Prefect Enterprise specifically, I don’t want to invent a procedure without verified docs. “How is default workspace provisioned?” Typically this would happen through: * an installation bootstrap step * an admin API/UI action after first login * or an internal provisioning process tied to your Enterprise configuration Since you only brought the server up and now see no accessible workspace, it strongly suggests that bootstrap provisioning was not completed. If you want to speed up resolution internally, gather: * Enterprise version * deployment method (
helm
, 
docker compose
, 
terraform
, etc.) * auth mode (
SSO
, OIDC, local auth) * whether all users see “no workspace access” * whether any bootstrap/init job logs mention admin, org, workspace, or RBAC setup Then use: Prefect contact If you want, I can help you draft a very short summary of the issue and the exact checks to perform in your deployment manifests/logs before you contact Prefect.
v
@Marvin where to configure this :"Usually in enterprise systems, one of these is used: * a bootstrap admin configured during installation * an identity/email configured as initial admin * SSO group/claim mapping to an admin role * a setup job/script run during deployment"
m
✅ thought for 9.4 seconds
I don’t want to guess here: for Prefect Enterprise customer-managed, I’m not aware of a publicly documented, self-serve location where you configure the initial bootstrap admin/workspace setup the way you would for open-source Server. So I can’t confidently point you to a supported file/env var/Helm value for: * initial admin email * first workspace creation * bootstrap RBAC mapping * first user assignment For Enterprise, those settings are typically part of the Enterprise deployment package / onboarding instructions, not the open-source docs. So the correct path is: Prefect contact A few things you can check in your own deployment artifacts, though, in case your package includes them: * Helm values files * Kubernetes secrets/configmaps * enterprise auth/SSO config sections * init jobs / bootstrap jobs * deployment README from your Enterprise bundle Look for keys/sections mentioning: * 
workspace
* 
rbac
* 
auth
* 
oidc
* 
sso
* 
bootstrap
* 
admin
* 
claims
* 
groups
But I don’t want to tell you “set X in Y” without verified Enterprise docs, because that would be risky. So short answer: I don’t have a verified public location for that Enterprise bootstrap config. Use: Prefect contact If you want, I can help you inspect your Helm values or deployment manifests and identify any likely bootstrap/auth settings.
3 Views
Open in Slack
PreviousNext
Powered by