# Convex.jl is a modelling layer that hands the problem to your solver

> Convex.jl is a Julia package for disciplined convex programming, with an expression layer for building optimisation problems and a solver layer that dispatches to Mosek, Gurobi, ECOS, SCS or GLPK through MathOptInterface. It also carries an experimental JuMP solver that reformulates nonlinear models into conic programs, though only for a limited subset.

**jump-dev/Convex.jl** — A Julia package for disciplined convex programming

- Repository: https://github.com/jump-dev/Convex.jl
- Website: http://jump.dev/Convex.jl/
- Stars: 599 · Forks: 122
- Language: Julia
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jump-dev-convex-jl

## Two layers, and the second one is yours to choose

Convex.jl is a Julia package for disciplined convex programming, and its structure is the reason it is useful. The upper layer is a modelling interface, where you build an expression tree of variables, constants and functions, wrap it in a problem with an objective and a list of constraints, and ask the package to solve it. The lower layer is a solver interface, and that is where the freedom lies. The package can solve linear programs, mixed integer linear programs and DCP compliant convex programs using a variety of solvers, including Mosek, Gurobi, ECOS, SCS and GLPK, all reached through MathOptInterface rather than through bespoke adapters for each one. That last detail is what makes the design durable. MathOptInterface is the common layer that the Julia optimisation ecosystem is built on, so supporting a new solver is a matter of the interface rather than a new integration inside Convex.jl, and switching a problem from a commercial solver to a free one is a change to one argument. The package also supports optimisation with complex variables and coefficients, which is unusual in a modelling layer and is listed as a headline capability rather than an afterthought.

## DCP is a rule set, not a hint

Disciplined convex programming is the framework Convex.jl implements, and the discipline part matters more than the convex part. In DCP, an expression is built from a small set of recognised atoms and compositions, and anything that does not fit the rules is rejected rather than approximated. The practical effect for a user is that a violation of the composition rules is an error at the point you build the expression, not a wrong answer at the point you solve it. That is the whole safety argument for the package: the class of problems you can express is exactly the class of problems the package can guarantee something about. It also means the rules are a learning curve, and a project that ports an existing optimisation code will hit them immediately, usually at the first composition that is not on the recognised list. The documentation set is split into a stable version and a development version on the project site, and the project also points to the DCP reference material hosted at Stanford, which is the right place to read the rules properly rather than to guess at them from error messages.

## The quick example shows the shape of a problem

The readme's example is a least squares problem with box constraints, and it is worth reading closely because it shows every moving part in about twenty lines. Random problem data is generated, a column vector variable of size n by one is created, and the problem is stated as minimising the sum of squares of the residual subject to the variable being between zero and one, built with the minimize function taking an objective and a list of constraints. Solving is a single call with the solver as an argument, and the result is inspected through the problem status and the optimal value.

```julia
import Pkg
Pkg.add("Convex")
```

```julia
using Convex, SCS
m = 4;  n = 5
A = randn(m, n); b = randn(m, 1)
x = Variable(n)
problem = minimize(sumsquares(A * x - b), [x >= 0, x <= 1])
solve!(problem, SCS.Optimizer)
problem.status
problem.optval
```

Three things are worth noticing. The solver appears once, at the solve call, so the same model can go to a different backend without being rewritten. The status is a separate query from the optimal value, which is the right way to write code that has to distinguish a solved problem from a failed one. And the constraints are written as ordinary expressions rather than as a separate specification object, so the code reads close to the mathematics.

## The JuMP bridge is experimental, and says so

Convex.jl contains an experimental JuMP solver, and the readme is careful about what that means. The solver reformulates a nonlinear JuMP model into a conic program using DCP, and it currently supports only a limited subset of scalar nonlinear programs, such as those involving log and exp. The example is a JuMP model with a variable constrained to be at least one, an auxiliary variable tied to the exponential of the first by a nonlinear constraint, and a minimisation of the auxiliary variable, solved through a Convex optimizer wrapping a conic solver, with the result printed as a pair of values that reproduce the familiar relationship between the exponential and its input. The judgement to make is about your model rather than the example. If your JuMP model is a small nonlinear program that happens to be expressible in the recognised subset, the bridge is a clean way to reuse a Convex solver in a JuMP workflow. If your model uses functions outside that subset, the reformulation will not apply, and the readme's own advice is to treat it accordingly rather than to expect it to work.

## A project with docs, benchmarks and a citation file

The repository is organised the way a mature scientific Julia package usually is. There is a Project.toml for the package definition, a source directory, a test directory, a documentation directory, a benchmark directory and a NEWS file for the changelog, along with a citation file, a prose linting configuration, a formatter configuration and a licence file. The Vale configuration is the detail that stands out, because Vale is a prose linter, and using one means the documentation is checked for writing issues in the same way the code is checked for style. The CI workflow badge and the codecov badge at the top of the readme indicate that tests and coverage are tracked, and the documentation is published in two channels, a stable version and a development version, which is the standard arrangement for a package where the development docs change with every merge. There is also a required citation, a BibTeX entry for the 2014 workshop paper on convex optimisation in Julia, and the readme asks that you cite the software if you use it in published work. The licence is a custom one that GitHub cannot classify, so the LICENSE.md file is the document to consult, and the release history shows steady work with v0.16.7 in August 2026, v0.16.6 in May and v0.16.5 in January, alongside a last push on 2026-08-19.

## Conclusion

Convex.jl earns its place for a team that wants to write optimisation problems as expressions and keep the freedom to change solver, because the solver is a parameter of the solve call rather than a property of the model, and the same problem can be sent to a commercial solver or to a free one. It is the wrong choice if you need the full JuMP nonlinear feature set, since that bridge is experimental and supports only a limited subset, and the wrong choice if your problem is not DCP compliant, because the package will not silently accept a non convex expression. Verify three things before you build on it: that your problem is DCP compliant, since the composition rules are enforced and a violation is an error rather than a wrong answer, which solver licences you have available, and how complex valued variables behave in your formulation, since complex support is a feature the readme lists separately. The last push was on 2026-08-19, the newest release is v0.16.7, and the licence is in the LICENSE.md file.

## FAQ

### How do I install Convex.jl?

Through the Julia package manager, by importing Pkg and calling Pkg.add with the package name Convex. The project is documented at jump.dev with separate stable and development documentation builds.

### Which solvers can Convex.jl use?

The package can solve linear programs, mixed integer linear programs and DCP compliant convex programs using Mosek, Gurobi, ECOS, SCS and GLPK, all through MathOptInterface. The solver is chosen when you call solve on the problem rather than when you build it.

### What does the experimental JuMP solver do?

It reformulates a nonlinear JuMP model into a conic program using DCP. The readme states that it currently supports only a limited subset of scalar nonlinear programs, such as those involving log and exp.

### What is disciplined convex programming in this context?

It is the modelling discipline Convex.jl implements, where an expression must be composed from recognised atoms and rules. A composition that breaks the rules is rejected at build time rather than solved incorrectly, which is what lets the package guarantee something about the problems it accepts.

## Sources

- [Issues](https://github.com/jump-dev/Convex.jl/issues)
- [jump-dev/Convex.jl on GitHub](https://github.com/jump-dev/Convex.jl)
- [Project website](http://jump.dev/Convex.jl/)
- [README](https://github.com/jump-dev/Convex.jl/blob/master/README.md)
- [Releases](https://github.com/jump-dev/Convex.jl/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jump-dev-convex-jl