# Workbench is a browser console for the Salesforce APIs, and Salesforce does not support it > Workbench is a PHP web application for administrators and developers to query, manipulate and migrate data and metadata in Salesforce organisations through the Force.com APIs, covering Partner, Bulk, REST, Streaming, Metadata and Apex. It suits a Salesforce admin who wants to explore an org from a browser, and it is explicitly not a supported Salesforce product. **forceworkbench/forceworkbench** — Web-based suite of tools for administrators and developers to interact with the Force.com APIs - Repository: https://github.com/forceworkbench/forceworkbench - Website: workbench.developerforce.com - Stars: 539 · Forks: 260 - Language: PHP - License: BSD-3-Clause - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/forceworkbench-forceworkbench ## What the tool actually covers Workbench is described as a powerful, web-based suite of tools for administrators and developers to interact with Salesforce.com organisations via the Force.com APIs. The API coverage is the substance of it. The README lists broad support for the Force.com Partner, Bulk, Rest, Streaming, Metadata and Apex APIs, and says this allows users to describe, query, manipulate and migrate both data and metadata in Salesforce.com organisations directly in a web browser with a simple and intuitive user interface. That list maps onto the ways a Salesforce admin actually works. The REST and Bulk APIs cover ordinary data, the Partner API is the classic interface for tooling, Metadata API is what you need to move configuration between orgs and to deploy, and Apex gives you a way to execute code for testing and troubleshooting. So the tool is a browser console for an organisation rather than a data browser. The Migrate and Describe operations, which come with the Metadata API, are the features that let you copy configuration between sandbox and production, and they are the reason the tool is used by more people than the query interface would suggest. The primary language is PHP, and the default branch is composerPhpFix, which tells you the current focus is on the Composer dependency management rather than on a new feature. ## The features aimed at debugging, not just querying The second half of the README description is about testing and troubleshooting the APIs themselves, and this is where Workbench differs from a plain query tool. The listed advanced features are customizable SOAP headers, debug logs for API traffic, backward compatibility testing with previous API versions, and single sign-on integration within the Salesforce application. Customizable SOAP headers matter when you are chasing a specific API behaviour. Being able to add a header that the interface does not expose by default is the difference between reproducing a client integration problem and not reproducing it. Debug logs for API traffic is the feature that saves the most time in practice. When a query behaves differently in Workbench than in your application, the request and response bodies are what settle the argument, and having them visible in the browser is worth a lot. Backward compatibility testing with previous API versions lets you check whether behaviour you relied on has changed, which is a genuine concern with a vendor API where a version bump can alter results without changing your code. The SSO integration within the Salesforce application means you can authenticate through Salesforce itself rather than entering credentials into a third-party form. ## Hosted, downloadable, or on Heroku There are three ways to get Workbench, and the choice depends on where your data may go. It is publicly hosted at workbench.developerforce.com, and also available for download from the project's tags for private installation. And it can be deployed to Heroku, which the README describes as great for spinning up a public instance during development in a fork. The Heroku option has a dedicated deploy button in the README, and the repository contains the pieces that make a one-button deploy work: an app.json, a Procfile and a Dockerfile. That last point is the one to weigh. A public Workbench instance is convenient for exploration, but a session there means entering your organisation credentials, or an OAuth token, into a server you do not control. For a sandbox that is fine. For a production organisation it is not, and the private download is the answer for that case. The README defers the actual installation steps to the wiki, pointing at the installation section of the project wiki rather than repeating them. The wiki also carries the FAQs, and the repository has a docs/ directory and a CHANGELOG.md for release history. ## The Docker compose stack and what it reveals The repository's docker-compose.yml is the clearest description of how the application runs, and it is small enough to read in one go. ```yaml version: '3' services: worker: &base build: . entrypoint: /app/local-development/docker-entrypoint-worker.sh volumes: - './workbench:/app/workbench' environment: PATH: '/app/.heroku/php/bin:/app/.heroku/php/sbin:$PATH' REDIS_URL: 'redis://redis:6379' links: - redis web: <<: *base entrypoint: /app/local-development/docker-entrypoint-web.sh environment: PATH: '/app/.heroku/php/bin:/app/.heroku/php/sbin:$PATH' PORT: 8080 REDIS_URL: 'redis://redis:6379' ports: - '8080:8080' redis: image: redis:alpine ports: - "6379:6379" ``` Three services. A web process on port 8080, a worker process, and Redis. The Redis dependency is there because the tool needs to hold session state, which for a console means the query context and the authentication between requests. The YAML anchor and merge on the worker definition is a small detail that shows the compose file is written for humans: the worker defines the base, and the web service inherits it and overrides the entrypoint and adds the port mapping. The compose file is aimed at local development rather than production, which the entrypoint paths confirm, since they live under local-development/. The volumes mount './workbench:/app/workbench', so the workbench/ directory of the repository is what the container serves. The repository also carries a local.sh script, a build.xml for Ant, an assets/ directory, a bin/ directory and a scripts/ directory, alongside the workbench/ application itself and the local-development/ setup. ## The Heroku buildpack heritage in the Dockerfile The Dockerfile shows that this application was built to run on Heroku's PHP stack, and it still is. ```dockerfile FROM heroku/heroku:16-build as base ENV PHP_BUILDPACK_VERSION v144 ENV APP /app ENV HOME $APP ENV HEROKU_PHP_BIN $APP/.heroku/php/bin ENV STACK heroku-16 ADD . $APP WORKDIR $APP RUN mkdir -p /tmp/buildpack/php /tmp/build_cache /tmp/env ADD https://github.com/heroku/heroku-buildpack-php/archive/$PHP_BUILDPACK_VERSION.tar.gz ./ RUN tar -xzvf $PHP_BUILDPACK_VERSION.tar.gz -C /tmp/buildpack/php --strip-components 1 && rm $PHP_BUILDPACK_VERSION.tar.gz RUN /tmp/buildpack/php/bin/compile /app /tmp/build_cache /tmp/env # Set up xdebug RUN $HEROKU_PHP_BIN/pecl install channel://pecl.php.net/xdebug-2.6.1 ``` The base image is heroku/heroku:16-build, the PHP buildpack version is pinned to v144, and the stack is named heroku-16. The compile step runs the buildpack's own compile script against the application, which is how a Heroku PHP app installs its dependencies. The xdebug line at the end is the clue to how this codebase is used. Xdebug is installed as a PHP extension through pecl, which only makes sense if you want step debugging or profiling on the application itself. For a console that runs queries on your behalf, that is a development and troubleshooting tool. The Dockerfile being pinned to a 2016-era Heroku stack tells you the deployment target has not moved in some time, and that is the same signal the release history gives. The listed releases are 65.0.0 from 2026-03-30, then 53.0.0 from 2021-08-24 and 52.0.0 from 2021-04-07. So version 65 was published in 2026 after a long gap from version 53, which suggests the project went quiet and has recently resumed, and that the numbering follows Salesforce's own API release cycle rather than a conventional semver cadence. ## The support statement, and what it means for adoption The README is unusually direct about support, and it belongs in any evaluation. Please note that the Workbench is NOT a supported product of or supported by salesforce.com, inc. For support from the Open Source community, the README points to a Stack Overflow tag for workbench and to the project's GitHub issues page for issues, bugs and feature requests. This matters more here than for most open source tools, because the thing you are pointing at someone else's production organisation. If an operation goes wrong, Salesforce will not help, and the community channels are volunteer effort. The mitigation is the same as for any admin tool, and it is worth stating plainly: work against a sandbox, and use the Metadata API Deploy operation with validation rather than destructive operations against production. The licence is BSD-3-Clause with the LICENSE.md file at the root, which is permissive and lets you self-host and modify freely without copyleft obligations. For a tool you install inside your own network, that combination, permissive licence plus no vendor support, is the normal shape of an unofficial admin console, and it is exactly what the private download is for. ## Where Workbench is the wrong choice Four cases argue against it. The first is anything that requires vendor support. The README states it outright. If your organisation has a policy that administrative tooling must be supported by the vendor, or if you are handling regulated data where an unsupported third-party console has to be justified to an auditor, this does not clear the bar. The second is a modern data platform workflow. The tool's centre of gravity is the metadata and query side of the Force.com APIs, which is exactly its strength, but a team running Bulk API loads through a managed pipeline, or building on the Salesforce CLI, gets more from tools that are actively maintained as part of the current Salesforce toolchain. The third is self-hosting without Heroku-shaped infrastructure. The compose file is a development setup with entrypoints under local-development/, and the Dockerfile is tied to a Heroku stack and a pinned PHP buildpack. Getting a production-grade deployment out of it means writing your own image, your own process supervision and your own TLS termination. The alternative in the same direction is the Salesforce CLI with its plugin ecosystem, which is the officially maintained way to script org operations, including the org commands for login, data operations and metadata deployment. The difference in approach is that the CLI is a client on your machine with credentials in your own config file, so nothing about your session passes through a third-party server, and it carries vendor backing. Workbench gives you a browser interface, which is genuinely faster for exploring an org and for showing a colleague what you are looking at, and the ability to run custom SOAP headers that the standard tooling does not expose. ## Conclusion Workbench fits a Salesforce administrator or integrator who wants to explore and debug an organisation from a browser, or a team that wants a self-hosted instance for API exploration without handing credentials to a public site. It does not fit anyone who needs vendor support, because the README states plainly that Workbench is not a supported product of salesforce.com. Use the public instance at workbench.developerforce.com for a quick look, install it yourself from the tags if your data cannot leave the network, and remember that a session there means your org credentials going to a third-party server. ## FAQ ### What is Workbench? Workbench is a web-based suite of tools for administrators and developers to interact with Salesforce.com organisations via the Force.com APIs. It supports the Partner, Bulk, REST, Streaming, Metadata and Apex APIs and runs in the browser, and the primary language is PHP. ### Is Workbench supported by salesforce.com? No. The README states plainly that the Workbench is NOT a supported product of or supported by salesforce.com, inc., and points to the Stack Overflow tag and the GitHub issues page for community support. ### Can I run Workbench myself instead of using the hosted instance? Yes. It is publicly hosted at workbench.developerforce.com and is available for download from the project's tags for private installation, and it can also be deployed to Heroku, which the README recommends for spinning up a public instance during development in a fork. ### What debugging features does Workbench offer? The README lists customizable SOAP headers, debug logs for API traffic, backward compatibility testing with previous API versions, and single sign-on integration within the Salesforce application. ### What licence is Workbench released under? BSD-3-Clause, with the LICENSE.md file at the repository root. The listed releases are 65.0.0 from 2026-03-30, then 53.0.0 from 2021-08-24 and 52.0.0 from 2021-04-07. ## Sources - [forceworkbench/forceworkbench on GitHub](https://github.com/forceworkbench/forceworkbench) - [Issues](https://github.com/forceworkbench/forceworkbench/issues) - [License: BSD-3-Clause](https://github.com/forceworkbench/forceworkbench/blob/composerPhpFix/LICENSE) - [README](https://github.com/forceworkbench/forceworkbench/blob/composerPhpFix/README.md) - [Releases](https://github.com/forceworkbench/forceworkbench/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/forceworkbench-forceworkbench