PyCaret 4.0: a sklearn-native AutoML engine with a FastAPI control plane and a React UI

The problem PyCaret 4.0 addresses: a modeling loop that lives in notebooks and never leaves

Most tabular machine learning work starts in a notebook and stays there. You import scikit-learn, write a preprocessing pipeline, loop over a dozen estimators, compare scores in a DataFrame you print to the cell output, then hand the winning estimator to someone else in a pickle file. Nothing about that loop is reproducible for the next person, and nothing about it survives a change of laptop. PyCaret's pitch is to compress the loop into a small number of calls and, in 4.0, to put a service around it so the loop has a home outside the notebook. The README describes the target audience indirectly through the quickstart: someone who can run Docker Desktop and open a browser, not necessarily someone who writes FastAPI services. The bundled sample datasets (juice, bank, iris) and the point-and-click experiment flow point at the same reader: a data scientist or analyst who wants a leaderboard without writing the leaderboard. The 4.0 revamp adds a second audience, the platform team that would otherwise assemble an internal ML tool from Airflow, MLflow and a homegrown UI. PyCaret bundles workspaces, projects, experiments, runs, a model registry, deployments, approvals, monitoring, drift, lineage, webhooks and schedules into the control plane. Whether that bundle is a gift or a liability depends on how much of it you would have built anyway.

How the engine, the control plane and the UI fit together

The README is explicit about the shape of the current release: a deliberately compact two-container deployment. One container, pycaret-web, serves a React bundle built with Vite through nginx on port 3020 and proxies /api and /ws to the backend. The other, pycaret-api, runs FastAPI with SQLAlchemy and APScheduler on port 8020, and that single process also runs the in-process scheduler, the in-process compute, and a local SQLite file. The README names the pattern directly, comparing it to how Plausible, Vaultwarden and n8n ship for self-hosters. Artifacts land in a named volume alongside the SQLite database: uploaded CSVs, fitted .pkl files, and a Fernet key. So the data flow for an experiment is: dataset uploaded or picked from a bundled sample, stored in the volume, a run created against a project, the in-process worker trains roughly twelve algorithms per the golden path, and the leaderboard ranks those trials on the run detail page. The architecture document referenced as PLATFORM_ARCHITECTURE.md describes the intended escape hatch: every external dependency (storage, DB, secrets, auth, queue, compute) is meant to sit behind a Protocol with multiple implementations, so the same codebase can target separate api, worker and runtime containers backed by RDS, S3, SecretsManager, SQS and Fargate. The README concedes that most of those Protocol extractions are still ahead. That sentence is the most important one in the document. It means the two-container shape is not a starting configuration you scale out of by flipping a flag today; it is the shape you get.

Getting it running: docker compose, two ports, and the .env knobs that matter

The install path is three commands. Clone the repository, change into it, run docker compose up --build. The README states the first build takes about five minutes because it installs Python dependencies, runs npm install and builds the Vite bundle; later starts are under thirty seconds. When the logs show pycaret-api with Application startup complete and pycaret-web starting nginx, the UI is at http://localhost:3020 and the API at http://localhost:8020. The setup screen then asks for a first admin account and workspace. Configuration is a .env file at the repository root, copied from .env.example. Four keys carry most of the weight. PYCARET_SECRETS_KEY is the Fernet key encrypting LLM API keys and connection passwords at rest; it is auto-generated on first run and persisted to the data volume, and the README says to set it explicitly only if you want the same key across multiple instances. PYCARET_JWT_SECRET signs auth tokens and must be a strong random value in any production deploy. PYCARET_DATABASE_URL swaps SQLite for Postgres via a postgresql+psycopg connection string. PYCARET_STORAGE_BACKEND=s3 plus bucket credentials moves artifacts off the local filesystem. Two operational facts deserve attention before you commit. First, docker compose down preserves the volume including the database and the Fernet key, while docker compose down -v wipes both. Second, the README states plainly that a forgotten admin password cannot be recovered because the database is encrypted, and the only remedy is the destructive down -v. That is a real operational hazard, not a documentation gap. Port conflicts are handled by environment variables at invocation time: PYCARET_WEB_PORT=3030 PYCARET_API_PORT=8030 docker compose up. The troubleshooting table also notes that on a very first up, the UI can load while every /api call returns 404 until Alembic migrations finish, roughly thirty seconds.

Where the single-binary shape breaks, and what the README admits

Running the scheduler, the compute and the API in one process is fine until it is not. The README says the compact shape is great for laptops and fine for a small-team production deploy, which is an honest boundary. The failure modes follow from that boundary rather than from any bug. A long training run competes with request handling in the same process, so the UI can stall while a run is in flight. Scaling horizontally is not a matter of adding replicas, because the scheduler is in-process and the database is a SQLite file on a volume; two API containers pointed at the same volume is not a configuration the README describes. The Postgres and S3 settings in .env move the database and artifacts, but the queue and compute separation that would let you run a dedicated worker pool is exactly the part the README says is still ahead. There is a second limitation that is easy to miss: the release is an alpha. The banner states that 4.0 is work in progress and that the 3.x line is frozen on PyPI as pycaret 3.4.0 with no further commits. So a team that needs a supported, non-alpha release has to choose between a frozen 3.x and an alpha 4.0, and the README does not present a third option. Anyone whose compliance process requires a stable version number should read that banner before anything else.

The LLM copilots and the encryption key they depend on

The control plane includes an optional LLM configuration: sidebar, Settings, LLM, paste an Anthropic or OpenAI API key, which the README says enables an AI dataset consultant and an experiment designer copilot. The design detail worth noting is where that key goes. It is encrypted at rest with the Fernet key held in PYCARET_SECRETS_KEY, which is auto-generated and stored in the data volume. That coupling has a consequence the README states in the troubleshooting table: because the database is encrypted, a lost admin password is unrecoverable and the fix is to wipe the volume. The same wipe destroys the auto-generated Fernet key, which means any stored LLM credentials and connection passwords go with it. For a laptop this is an inconvenience. For a shared deployment it is a reason to set PYCARET_SECRETS_KEY explicitly and back it up separately, which is the one scenario the README gives for setting it by hand. The copilots themselves are optional; nothing in the golden path requires an API key, and the bundled sample datasets let you run the full experiment flow without configuring an LLM at all. Treat the LLM settings as a feature you opt into after the base install works, not as part of the install.

PyCaret against a plain scikit-learn pipeline

The honest alternative for most of PyCaret's engine work is a scikit-learn Pipeline plus a manual loop over estimators, which is what PyCaret wraps. The difference in approach is not the algorithms, since the README states the engine is sklearn-1.7-based, but what comes attached. A hand-written pipeline gives you a Python object you control completely, testable with pytest, versionable in the same repository as the rest of your code, and free of any service to run. PyCaret 4.0 gives you that same modeling surface plus a FastAPI service, a React UI, a model registry, approvals, drift monitoring and lineage, all of which you would otherwise assemble from separate tools. The trade is operational surface for built-in structure. If your team already runs a model registry and a scheduler, adopting PyCaret 4.0 means either duplicating those functions or migrating to PyCaret's versions, and the README does not describe an import path from an existing registry. If your team has none of them and would otherwise build them, the two-container bundle is a smaller amount of code to own. The decision hinges on that, not on the algorithm count, which is roughly twelve trials per run according to the golden path and is not the differentiating factor.

Maintenance, release cadence and the license metadata

The release history in the repository metadata shows 3.3.2 in April 2024, then nothing until the two 4.0 alphas in April 2026, v4.0.0a0 and v4.0.0a1 a day apart. The README confirms the 3.x line is frozen at pycaret 3.4.0 on PyPI with no further commits. That cadence tells you the 3.x branch will not receive fixes, so staying on it is a deliberate freeze rather than a supported position. Upgrading from 3.x to 4.0 is described as a ground-up architectural revamp, which means you should not assume API compatibility between the two lines; the README does not offer a migration guide in the material provided. On licensing, the repository metadata reports NOASSERTION, which means the automated license detection could not classify the LICENSE file. That is a metadata state, not a license grant, and it is worth reading the LICENSE file directly before adopting the project in a commercial setting. I am not giving legal advice here; the point is that the machine-readable field does not answer the question a procurement reviewer will ask. The Python version badge lists 3.11, 3.12 and 3.13, so pinning to an older interpreter is not an option the project advertises. For upgrade cost specifically, the practical measure is how much of your code touches PyCaret's own API versus plain scikit-learn estimators, because the latter is portable across the 3.x to 4.0 boundary and the former is not.

Editorial conclusion

Adopt PyCaret 4.0 if you want a self-hosted AutoML surface you can run with docker compose up and you accept that the 4.0 line is an alpha with a frozen 3.x predecessor. Do not adopt it for regulated production work that needs a supported release, or for distributed training that needs separate worker and runtime containers, because the README states most of those Protocol extractions are still ahead. Before committing, verify the STATUS.md and ROADMAP.md gap matrix against your deployment shape, confirm whether the NOASSERTION license metadata on the repository matches the LICENSE file, and check that your target Python is 3.11, 3.12 or 3.13 as the badge claims.

Official sources

1. Issues
2. Project website
3. pycaret/pycaret on GitHub
4. README
5. Releases