In our MCP server, we’ve replaced the
flag with a new, more flexible disableRunCodeTool
argument. This change gives users fine-grained control over which tools are enabled.tools
You can now define which tools are enabled by using a comma-separated list of built-in tool categories and process tags:
run_code
: Enables the code execution tool
executions
: Enables execution management tools
env_vars
: Enables environment variable management tools
storage
: Enables storage management tools
mcp-tool
, core
, api
, automation
, etc.).
When specified, all processes with that tag are exposed as individual MCP tools.If no tools are specified, all built-in tools are enabled by default, but no process tools are exposed.
Example SSE URL definition:
https://cloud.yepcode.io/mcp/sk-c2E....RD/sse?mcpOptions=runCodeCleanup&tools=run_code,storage,env_vars,core,api
We’ve upgraded our execution engine to Firecracker version 13, bringing significant improvements in performance, security, and efficiency. This upgrade enhances isolation between executions, reduces startup latency, and improves resource utilization — making your processes faster and more reliable. Firecracker 13 also includes the latest security patches and optimizations, ensuring a safer and smoother execution environment.
At YepCode, we prioritize keeping our execution engine and dependencies up to date. This upgrade is part of our ongoing commitment to maintain cutting-edge performance and security for all users.
We’ve enhanced the execution row display to include both the startup delay (the time it took for the execution to begin) and the total duration. These two metrics are now shown together in the same cell for easier comparison. Additionally, hovering over the cell reveals the full execution timeline for more detailed insights.
We’ve upgraded our runtime environments to Node.js 22.19 and Python 3.13.7, bringing improved performance, stability, and access to the latest language features.
At YepCode, we always keep our runtimes up to date so you can rely on a secure, efficient, and future-proof execution platform.
Before this feature, a webhook async execution always answer a body like this:
{"id":"cb045e6a-48e4-4bc4-a7be-a09bca0ffbe5","status":"CREATED","data":null}
Now, if a query param (async_response) is provided, that content will be the response body.
For example this request "cloud.yepcode.io/api/xxxx/webh... on it'" will respond Working on it. If we provide false as async_response, no body will be provided.
HTTP codes won’t be affected.
You can now modify an existing schedule directly instead of needing to delete it and create a new one. This makes adjustments much faster and smoother.
We’ve improved our Local Disk feature, which lets your processes store and access files on the execution environment’s local filesystem. These enhancements make file handling faster, more reliable, and better integrated with other YepCode capabilities.
For more details, see our Local Disk documentation.
We’ve added YepCode Storage, a secure and integrated way to store and manage data directly from your YepCode projects. Use it to persist files, configuration, or intermediate results between executions without relying on external services.
For more details, see our official YepCode Storage documentation.
You can now install dependencies directly from Git repositories, not just from public package registries.
This allows you to use specific commits, branches, or repositories in your projects.
For more details, check our official documentation on dependencies.
Previously, if you hit your execution quota, new executions were rejected.
Now, they are automatically queued and will run once quota becomes available.
The maximum number of queued executions depends on your plan — some plans allow unlimited queuing.