--- title: "Certified plugins and stateless components" description: "Why certified plugins share workers and how to implement stateless-v1 components." --- Certification means that an exact immutable plugin artifact is approved for cross-tenant sharing in LangBot Cloud; it is not a general quality or safety badge. An installed artifact with a valid trusted certificate must run in shared mode, not dedicated mode. A marketplace **Certified Plugin** badge alone does not prove that the downloaded ZIP passes verification or that a live Worker is shared. Installations of the same artifact digest share one Worker, one `BasePlugin` object and one instance of each component. Each installation contributes only lightweight configuration, authority and lifecycle context. “Each component” means one instance for every declared component manifest across EventListener, Tool, Command, KnowledgeEngine, Parser, Page and Runner. ## Declaration ```yaml execution: python: path: main.py attr: Plugin sharedRuntime: shared-runtime-v1 componentModel: stateless-v1 ``` Both fields are required. The declaration is an application, not approval: authenticated artifact-bound advisory source review, explicit human approval and a valid trusted signature over the exact artifact remain mandatory. Advisory review is an internal prerequisite, not an intermediate certification tier. ## Stateless component contract - Plugin and component `initialize()` methods are process-scoped and run once per Worker. - Component objects must be re-entrant because calls from multiple Workspaces can overlap. - On `BasePlugin`, read installation configuration with `self.get_config()`. In a component, use `self.get_plugin_config()` or `self.plugin.get_config()`. - Never retain configuration, credentials, Workspace/installation identity or request data in instance fields or module globals. - Do not capture tenant configuration in `initialize()`. - Use SDK Host APIs for storage, files, credentials, logs, models and other platform capabilities. Authority comes from the task-local invocation context. - Durable tenant state belongs in Host services. Process caches may contain artifact-level public data only, or must use the complete installation binding as their key and support revocation cleanup. - Tenant-bearing detached tasks and threads are forbidden in `stateless-v1`; the SDK does not yet expose a plugin-facing ownership/revocation API. The contract intentionally preserves serverless-ready semantics, but current releases still run long-lived Workers and do not offer a serverless deployment mode. ## Configuration example ```python class LookupTool(Tool): async def initialize(self): self.transport = StatelessHTTPTransport() async def call(self, params, **kwargs): config = self.get_plugin_config() return await self.transport.lookup(config["endpoint"], params) ``` Do not retain tenant data during process initialization: ```python async def initialize(self): self.endpoint = self.plugin.config["endpoint"] self.api_key = self.plugin.config["api_key"] ``` Shared initialization has no tenant config, so this reads empty/stale data or fails. Any attempt to retain invocation config on the shared object blocks certification. ## Legacy compatibility Legacy source and unsigned packages remain compatible on dedicated Workers, including unsigned Cloud installs. There is no dedicated certification or dedicated signature. Cloud must reject malformed, forged, untrusted or legacy signed certificates lacking the `stateless-v1` claim; they are not unsigned fallbacks. OSS ships without a built-in certification issuer public key, supports one Workspace and does not support configuring a key to enable shared-certified execution. Existing installations and a marketplace badge are not proof of shared Worker placement. Changing only the manifest does not satisfy certification review.