facebook/prophet: automatic forecasting for seasonal time series, now in maintenance mode

The forecasting problem Prophet was built to absorb

Most teams that need a forecast do not start with a statistics problem. They start with a table of daily or weekly numbers, a deadline, and a business question about next quarter. Fitting an ARIMA model means choosing orders, testing for stationarity and differencing, and redoing that work every time the series changes shape. Prophet takes a different route: it assumes the series is a sum of interpretable pieces, fits them together, and gives you a forecast with uncertainty intervals without you specifying a model order.

The README is explicit about the intended shape of the data. It works best, according to the project, with series that have strong seasonal effects and several seasons of historical data. It also states that the procedure is tolerant of missing data, shifts in trend, and outliers. That combination describes a lot of operational data: web traffic, retail sales, call volume, signups. The examples directory in the repository carries files like example_air_passengers.csv, example_retail_sales.csv and example_wp_log_peyton_manning.csv, which is a fair sketch of the kind of series the authors had in mind.

The audience is correspondingly narrow in a useful way. Prophet is for analysts and engineers who want a defensible baseline forecast they can explain to someone else, not for researchers chasing the last fraction of accuracy on a benchmark. If your series has no calendar structure, Prophet's main advantage evaporates.

Additive decomposition and the Stan backend

Prophet's model is additive. The README describes it as an additive model where non-linear trends are fit with yearly, weekly and daily seasonality, plus holiday effects. In practice that means the forecast is assembled from a trend component that can bend, a set of periodic components tied to the calendar, and a holiday component driven by a country holiday table. Because the components are separate, you can plot them separately and see whether a spike in the forecast comes from the trend or from a holiday.

Fitting is not done in pure Python. The package compiles and runs Stan model executables, and the README notes that by default Prophet uses a fixed version of cmdstan, downloading and installing it if necessary. That detail explains most of the installation friction people hit: the first install is not just a wheel drop, it involves compiling model code. The README also documents an escape hatch, the PROPHET_REPACKAGE_CMDSTAN environment variable, for users who already have their own cmdstan and do not want Prophet to fetch another copy.

The R side has a comparable choice. The README describes cmdstanr as an experimental alternative backend, selected by setting the R_STAN_BACKEND environment variable to CMDSTANR after installing cmdstanr and posterior. That is a meaningful architectural difference from the default rstan path, and the word experimental in the README should be taken at face value.

Installing Prophet with pip or conda, and a first forecast

The Python package is on PyPI and the README gives a single install command. Note the package name history: the README states that as of v1.0 the PyPI package is named prophet, and that before v1.0 it was fbprophet. Older tutorials that still say fbprophet are describing a name that no longer exists.

python -m pip install prophet

Conda users have a second route through conda-forge, which the README lists as an alternative to pip.

conda install -c conda-forge prophet

On Linux the README warns that compilers (gcc, g++, build-essential) and Python development headers must be present, and that a VM needs at least 4GB of memory to install and at least 2GB to run Prophet. On Windows it notes that using cmdstanpy requires a Unix-compatible C compiler such as mingw-gcc, installable through cmdstanpy.install_cxx_toolchain. The minimum supported Python version stated in the README is 3.7, as of v1.1.

The repository also ships a Dockerfile and a docker-compose.yml, with a Makefile exposing build, py-shell and shell targets. The Dockerfile is based on python:3.7-stretch and installs the package in editable mode with the dev and parallel extras, so it is aimed at development rather than at a slim production image.

Once installed, the documented entry point is the quick start guide, which covers both the Python and R APIs. The repository's examples directory gives you real input files to try, including example_air_passengers.csv and example_retail_sales.csv, both of which have the two-column date and value shape Prophet expects. A first run means loading one of those, fitting, and asking for a forecast horizon; the quick start page is where the exact call signatures live, and the README does not restate them.

Where Prophet stops being the right tool

The most important limitation is stated by the project itself, in the README's 2026 update. Prophet is in maintenance mode as of v1.4.0. Only bug fixes, dependency bumps, and changes to the R package to meet parity with Python will be accepted, and no new features are planned. That is a policy statement, not a rumour, and it changes the calculus for anyone planning a multi-year dependency. You are adopting a frozen feature set.

The second limitation is structural. Because the model is additive with calendar-driven seasonality, it is a poor match for series whose behaviour is driven by external variables rather than by the passage of time. The v1.4.0 release notes mention supported nested Prophet models for extra regressors, so regressors exist, but the core design still assumes the calendar does most of the explanatory work. For high-frequency financial series, or for series where a known intervention dominates, a model built around those drivers will usually be the better choice.

The third is operational. The README's memory guidance, 2GB to use Prophet, is per-process and not trivial. If you need to forecast a very large number of short series, the Stan compile-and-fit path is heavier than a lightweight statistical method would be. The README does not document a distributed fitting mode, and nothing in the release notes suggests one was added.

Prophet against a plain seasonal baseline

The most honest comparison is not against another forecasting library but against the baseline most teams already have: a seasonal naive forecast, where next week equals the same week last year, or a simple exponential smoothing model. Those methods need no compiler, no Stan, and no 2GB of headroom. They are also surprisingly hard to beat on stable series.

Prophet's difference in approach is that it estimates the seasonal shape from all available history rather than copying a single period, and it fits trend changepoints so that a series which levels off is not extrapolated upward forever. It also attaches uncertainty intervals to the forecast, which a naive baseline does not give you. The price is the install complexity and the runtime.

A second comparison worth naming is the general-purpose machine learning route: build lag features and calendar features, then fit a gradient boosting model. That approach handles external drivers naturally and trains fast, but it gives you no decomposition, no built-in holiday table, and no interval estimates without extra work. Prophet's value is the packaging of all three into one object with a small API. If you already have a feature pipeline and a boosting model in production, Prophet is unlikely to displace it; if you have nothing, Prophet gets you to a defensible forecast faster.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-08-27, so the codebase is still receiving commits. The README's maintenance-mode statement, however, tells you what kind of commits to expect: fixes, dependency bumps, and R parity work. The most recent release listed is v1.4.0-patched on 2026-08-15, following v1.4.0 on 2026-08-01 and v1.3.0 on 2026-01-27. A patched release two weeks after a minor release is consistent with the stated policy.

Upgrade cost is dominated by dependency churn rather than by API change. The release notes show the project actively tracking the Python data stack: v1.2.2 added version constraints on pandas below 3 and numpy below 2.4, and v1.3.0 then added support for pandas 3.0 and numpy 2.4. If your environment pins pandas or numpy for other reasons, read those two entries together before upgrading, because the constraint and its removal bracket the same window. The R package has its own constraint: v1.2.2 updated R build requirements to C++17 to comply with CRAN policy.

Prophet is MIT licensed. That is a permissive licence, and it is the same for the Python and R packages. Nothing here is legal advice, and the LICENSE file in the repository root is the authoritative text. The practical implication for most teams is that MIT imposes few obligations beyond retaining the copyright and permission notice, but if you redistribute Prophet inside a product, read the file rather than this summary.

Editorial conclusion

Adopt Prophet when you have several seasons of history, strong weekly or yearly patterns, and holiday effects you want to model without hand-building feature columns. Do not adopt it if you need a model that is still gaining capabilities, if your series is short or has no seasonality, or if you need to forecast thousands of series quickly. Before committing, verify that your Python version satisfies the minimum the README states, check that the holiday data for your country is current enough, and confirm that the maintenance-mode policy in the README matches your expectations for the next year. The release notes are the place to check what actually changed between v1.3.0 and v1.4.0.

Frequently asked questions

Official sources

1. facebook/prophet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases