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 uses additive seasonality by default, fitting non-linear trends with yearly, weekly and daily seasonality plus holiday effects. It also supports multiplicative seasonality, where seasonal effects scale with the trend. 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: a source 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 the pre-v1.0 package name.

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. 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.

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 consideration is whether the model captures the drivers of the series. Prophet supports additional regressors as well as additive or multiplicative seasonality, but regressor values must be available for both historical and future prediction dates. Compare its forecasts against suitable baselines and alternative models for your data.

The third is operational. The README's memory guidance, 2GB to use Prophet, is 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. For distributed fitting, the README points to Helter Skelter, a separate simplified reimplementation of Prophet in Scala for Apache Spark, maintained by Amadeus.

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 can incorporate external drivers through features, but decomposition, holiday features and interval estimates require additional work. Prophet can also use extra regressors when their future values are available. 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-10-22, 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.5.0 on 2026-10-05, following v1.4.0-patched on 2026-08-15 and v1.4.0 on 2026-08-01. The v1.5.0 changelog is a list of fixes, which is consistent with the stated policy.

Upgrade cost is dominated by dependency churn rather than by API change. The maintenance policy explicitly accepts dependency bumps, so if your environment pins pandas or numpy for other reasons, read the release notes before upgrading.

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.4.0 and v1.5.0.

Frequently asked questions

Official sources

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