{
  "schema_version": 2,
  "id": "develop/ai/redisvl/user_guide/installation",
  "title": "Install RedisVL",
  "url": "https://redis.io/docs/latest/develop/ai/redisvl/0.26.0/user_guide/installation/",
  "summary": "",
  "content": "\n\nThere are a few ways to install RedisVL. The easiest way is to use pip.\n\n## Install RedisVL with Pip\n\nInstall `redisvl` into your Python (\u003e=3.10) environment using `pip`:\n\n```bash\n$ pip install -U redisvl\n```\n\nRedisVL comes with a few dependencies that are automatically installed, however, several optional\ndependencies can be installed separately based on your needs:\n\n```bash\n# Vectorizer providers\n$ pip install redisvl[openai]              # OpenAI embeddings\n$ pip install redisvl[cohere]              # Cohere embeddings and reranking\n$ pip install redisvl[mistralai]           # Mistral AI embeddings\n$ pip install redisvl[voyageai]            # Voyage AI embeddings and reranking\n$ pip install redisvl[sentence-transformers]  # HuggingFace local embeddings\n$ pip install redisvl[google-genai]        # Google embeddings (Vertex AI + Gemini API)\n$ pip install redisvl[vertexai]            # Google Vertex AI embeddings (legacy; deprecated, multimodal only)\n$ pip install redisvl[bedrock]             # AWS Bedrock embeddings\n\n# Other optional features\n$ pip install redisvl[mcp]                 # RedisVL MCP server support (Python 3.10+)\n$ pip install redisvl[langcache]           # LangCache managed service integration\n$ pip install redisvl[sql-redis]           # SQL query support\n```\n\nIf you use ZSH, remember to escape the brackets:\n\n```bash\n$ pip install redisvl\\[openai\\]\n```\n\nYou can install multiple optional dependencies at once:\n\n```bash\n$ pip install redisvl[mcp,openai,cohere,sentence-transformers]\n```\n\nTo install **all** optional dependencies at once:\n\n```bash\n$ pip install redisvl[all]\n```\n\n## Install RedisVL from Source\n\nTo install RedisVL from source, clone the repository and install the package using `pip`:\n\n```bash\n$ git clone https://github.com/redis/redis-vl-python.git \u0026\u0026 cd redis-vl-python\n$ pip install .\n\n# or for an editable installation (for developers of RedisVL)\n$ pip install -e .\n```\n\n## Development Installation\n\nFor contributors who want to develop RedisVL, we recommend using [uv](https://docs.astral.sh/uv/) for dependency management:\n\n```bash\n# Clone the repository\n$ git clone https://github.com/redis/redis-vl-python.git \u0026\u0026 cd redis-vl-python\n\n# Install uv if you don't have it\n$ pip install uv\n\n# Install all dependencies (including dev and docs)\n$ uv sync\n\n# Or use make\n$ make install\n```\n\nThis installs the package in editable mode along with all development dependencies (testing, linting, type checking) and documentation dependencies.\n\n### Running Tests and Linting\n\n```bash\n# Run tests (no external APIs required)\n$ make test\n\n# Run all tests (includes API-dependent tests)\n$ make test-all\n\n# Format code\n$ make format\n\n# Run type checking\n$ make check-types\n\n# Run full check (lint + test)\n$ make check\n```\n\n### Pre-commit Hooks\n\nWe use pre-commit hooks to ensure code quality. Install them with:\n\n```bash\n$ pre-commit install\n```\n\nRun hooks manually on all files:\n\n```bash\n$ pre-commit run --all-files\n```\n\n## Installing Redis\n\nRedisVL requires Redis with [Redis Search](https://redis.io/docs/latest/develop/ai/search-and-query/) available. There are several options:\n\n1. [Redis Cloud](https://redis.io/cloud), a fully managed cloud offering with a free tier\n2. [Redis 8+ (Docker)](https://redis.io/downloads/), for local development and testing\n3. [Redis Software](https://redis.io/software/), a commercial self-hosted option\n\n### Redis Cloud\n\nRedis Cloud is the easiest way to get started with RedisVL. You can sign up for a free account [here](https://redis.io/cloud). Make sure to have `Redis Search`\nenabled when creating your database.\n\n### Redis 8+ (local development)\n\nFor local development and testing, we recommend running Redis 8+ in a Docker container:\n\n```bash\ndocker run -d --name redis -p 6379:6379 redis:8.4\n```\n\nRedis 8 includes Redis Search and built-in vector search capabilities.\n\n### Redis Software (self-hosted)\n\nRedis Software is a commercial offering that can be self-hosted. You can download the latest version [here](https://redis.io/downloads/).\n\nIf you are considering a self-hosted Redis Software deployment on Kubernetes, there is the [Redis Software Operator](https://docs.redis.com/latest/kubernetes/) for Kubernetes. This will allow you to easily deploy and manage a Redis Software cluster on Kubernetes.\n\n### Redis Sentinel\n\nFor high availability deployments, RedisVL supports connecting to Redis through Sentinel. Use the `redis+sentinel://` URL scheme to connect. Both sync and async connections are fully supported.\n\n```python\nfrom redisvl.index import SearchIndex, AsyncSearchIndex\n\n# Sync connection via Sentinel\n# Format: redis+sentinel://[username:password@]host1:port1,host2:port2/service_name[/db]\nindex = SearchIndex.from_yaml(\n    \"schema.yaml\",\n    redis_url=\"redis+sentinel://sentinel1:26379,sentinel2:26379/mymaster\"\n)\n\n# Async connection via Sentinel\nasync_index = AsyncSearchIndex.from_yaml(\n    \"schema.yaml\",\n    redis_url=\"redis+sentinel://sentinel1:26379,sentinel2:26379/mymaster\"\n)\n\n# With authentication and database selection\nindex = SearchIndex.from_yaml(\n    \"schema.yaml\",\n    redis_url=\"redis+sentinel://user:pass@sentinel1:26379,sentinel2:26379/mymaster/0\"\n)\n```\n\nThe Sentinel URL format supports:\n\n- Multiple sentinel hosts (comma-separated)\n- Optional authentication (username:password)\n- Service name (defaults to `mymaster` if not specified)\n- Optional database number (defaults to 0)\n- Both sync (`SearchIndex`) and async (`AsyncSearchIndex`) connections\n\n## Redis permissions (ACLs)\n\nRedisVL reaches Redis through Redis Search commands, but not all of them need the `@search` category. Querying and loading work under an ordinary `+@read +@write` role; it is the commands that inspect or manage an index — `FT.INFO`, `FT.CREATE`, `FT._LIST` — that need `@search` or an explicit grant.\n\nThe command-to-category mapping below was measured against live servers rather than quoted from published documentation, which does not list ACL categories per `FT.*` command. It was identical on Redis 8.0.6, 8.2.7, 8.4.5, 8.6.4, 8.8.0 and 8.8.1. Check your own deployment with `COMMAND INFO ft.info`, `ACL CAT search`, or `ACL DRYRUN \u003cuser\u003e FT.INFO \u003cindex\u003e`.\n\n### What each operation needs\n\n| Operation                                                                                                       | Redis command                           | `+@all -@admin`   | `+@read +@write`   |\n|-----------------------------------------------------------------------------------------------------------------|-----------------------------------------|-------------------|--------------------|\n| `index.query()`, `index.search()`, `index.aggregate()`                                                          | `FT.SEARCH`, `FT.AGGREGATE`             | Yes               | Yes                |\n| `index.load()`                                                                                                  | `HSET` or `JSON.SET` (needs key access) | Yes               | Yes                |\n| `index.exists()`, `index.info()`, `index.clear()`, `SearchIndex.from_existing()`, `rvl index info`, `rvl stats` | `FT.INFO`                               | Yes               | **No**             |\n| `index.create()`                                                                                                | `FT.CREATE`                             | Yes               | **No**             |\n| `index.delete()`, `rvl index delete`, `rvl index destroy`                                                       | `FT.DROPINDEX`                          | Yes               | Yes                |\n| Enumerating indexes (see below)                                                                                 | `FT._LIST`                              | **No**            | **No**             |\n\nExcept for `FT.CREATE`, every `Yes` above assumes key patterns that cover the index prefix — see [Key permissions](). `FT.CREATE` is not checked against those patterns, so a credential can create an index it cannot query. Adding `-@dangerous` to the second column additionally denies `FT.DROPINDEX`, so `index.delete()` becomes `No`. An SVS-VAMANA schema needs more than `FT.CREATE`: `index.create()` first probes capabilities with `INFO` (`@slow @dangerous`) and `MODULE LIST` (`@admin @slow @dangerous`), so both `-@admin` and `-@dangerous` policies break creation for those schemas.\n\nTwo of the rows above deserve their own explanation.\n\n`FT._LIST` is tagged `@admin` as well as `@search` and `@slow`, and ACL rules are applied left to right — so a rule that grants search access and then takes back administrative commands, such as `+@search -@admin` or `+@all -@admin`, denies it:\n\n```text\nUser \u003cname\u003e has no permissions to run the 'FT._LIST' command\n```\n\n`FT._LIST` does not *require* `@admin`: granting `+@search` on its own permits it. Only rules that subtract `@admin` after granting search are affected. To keep such a policy and still enumerate indexes, grant the command back explicitly with `+ft._list`. Enumeration is reached by `SearchIndex.listall()` and `AsyncSearchIndex.listall()`, by `rvl index listall`, and by the migration entry points that discover indexes for you: `rvl migrate helper`, `rvl migrate wizard` when no `-i/--index` is given, and `rvl migrate batch-plan --pattern`.\n\n`FT.DROPINDEX` is tagged `@dangerous` and `@write` as well as `@search`, so a policy that subtracts `@dangerous` denies `index.delete()`, `rvl index delete`, and `rvl index destroy`.\n\n### Roles built from `@read` and `@write`\n\n`FT.INFO` is in neither `@read` nor `@write` — its only category is `@search` — and `FT.CREATE` is the same. So an application role assembled from `+@read +@write -@dangerous` — a natural least-privilege shape for a runtime that must query and load but must not manage indexes — can query and load, but cannot ask whether an index exists and cannot create or drop one. Subtracting `@dangerous` is not what denies `FT.INFO` or `FT.CREATE`: `+@all -@dangerous` permits both. Those commands are simply never granted by `@read` or `@write`.\n\nEvery extension constructor checks whether its index exists, so under such a credential all of them fail while being constructed:\n\n```text\nRedisSearchError: Error while fetching llmcache index info:\nUser \u003cname\u003e has no permissions to run the 'FT.INFO' command\n```\n\n### \"no permissions to run the ‘FT.INFO’ command\"\n\nRedisVL does not guess its way around this. A credential that cannot ask whether the index exists also cannot create one, so there is nothing useful to infer — instead, tell RedisVL that the index is already there:\n\n```python\ncache = SemanticCache(\n    name=\"llmcache\",\n    redis_url=\"redis://localhost:6379\",\n    create_index=False,\n)\n```\n\n`create_index=False` is available on `SemanticCache`, `MessageHistory`, `SemanticMessageHistory` and `SemanticRouter`. It skips the existence check, the comparison of your schema against the live index, and index creation — the constructor issues no index command at all. Pass it when the index is managed externally, or when the credential cannot run `FT.INFO`. It cannot be combined with `overwrite=True`, which asks for the opposite.\n\nA `SearchIndex` used directly needs nothing special: build it with `from_dict()` or `from_yaml()`, then load and query. Two of its methods stay unavailable, because both read index metadata: `from_existing()`, which reconstructs a schema out of Redis, and `clear()`, which starts by calling `info()`.\n\nThe flag also skips the SVS-VAMANA capability probe described above, since that runs inside `create()`.\n\n### Provisioning a router\n\n`SemanticRouter` with `create_index=False` writes nothing at all: not the reference vectors for its routes, and not the stored route config that `SemanticRouter.from_existing()` reads. Preparing a router for this mode therefore means constructing it once with a privileged credential — a hand-written `FT.CREATE` is not enough, because the reference vectors have to be embedded and written too. Without them the router matches nothing, which looks like a distance-threshold problem rather than an empty index.\n\nAfterwards, `SemanticRouter.from_existing(name, create_index=False)` is the way to attach to it: it recovers the routes and thresholds with `JSON.GET` and needs no `FT.INFO`. The stored config must contain the full route set. Each route’s distance threshold is applied from that recovered list, so an incomplete stored config silently narrows matching — and `add_route()` and `remove_route()` rewrite the stored config from the same list, so mutating an incomplete config permanently drops the omitted routes from the config every other client reads.\n\n### When the schema diverges\n\nWith `create_index=False` nothing verifies that the live index matches the schema you described. Some mismatches are loud on first use, and several are silent:\n\n| Mismatch                                                     | What happens                                                                                                                                                                                                                                                                       |\n|--------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| The index does not exist                                     | `RedisSearchError` on the first query, naming the missing index                                                                                                                                                                                                                    |\n| Vector dimensions disagree                                   | `Error parsing vector similarity query: query vector blob size (32) does not match index's expected size (16)` — but only once the index holds a document. On an empty index the same query returns nothing, so a freshly provisioned index hides this until the first write lands |\n| The prefix does not cover your keys                          | **Silent.** Documents are written but never indexed, so queries return nothing, forever                                                                                                                                                                                            |\n| The index is `ON JSON` and you write hashes (or the reverse) | **Silent**, the same way                                                                                                                                                                                                                                                           |\n| The datatype or distance metric differs                      | **Silent.** Neither is restated by a query, so nothing compares them — results come back ranked by the index’s metric, not yours                                                                                                                                                   |\n\nFor the silent cases the tell is `FT.INFO`’s `key_type`, `prefixes` and `attributes` — not `hash_indexing_failures`, which stays `0` because those keys were never indexing candidates. Diagnosing it therefore needs a credential that can run `FT.INFO`.\n\nAn extension constructed with `create_index=False` refuses index-wide `delete()` and `clear()` operations (and their async cache equivalents). This protects an externally managed index — including an index reached through an alias — from being destroyed through an attach-only instance. Targeted operations such as dropping a specific cache entry or message remain available. Perform lifecycle-wide destructive operations through the privileged provisioning path that owns the index.\n\n### Key permissions\n\nCommand categories are only half of it. Redis also scopes the search commands by key pattern: [the ACL documentation](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/#command-categories) states that only users with access to a *superset* of the prefixes defined at index creation can create, modify, or read an index.\n\nMeasured on 8.4.5 against an index prefixed `doc:`, with the command categories held constant at `+@all`:\n\n| Key patterns                      | `FT.SEARCH`, `FT.INFO`, `FT.AGGREGATE`                                  |\n|-----------------------------------|-------------------------------------------------------------------------|\n| `~doc:*` (superset)               | Permitted                                                               |\n| `%R~doc:*` (read permission only) | Permitted                                                               |\n| `~doc:1` (partial overlap)        | `NOPERM User does not have the required permissions to query the index` |\n| `~other:*` (no overlap)           | The same denial                                                         |\n\nPartial overlap is worth emphasising: it fails exactly like no overlap at all, rather than returning the subset you can read. `FT.CREATE` is not checked this way, so a credential can create an index it is then unable to query.\n\n`create_index=False` does not help here — the very commands it lets you avoid are joined by the ones it cannot, so widen the key patterns instead.\n\nOutside of Redis Search, RedisVL identifies itself on connect with `CLIENT SETINFO`. That command is tagged `@connection` and `@slow`, and belongs to neither `@read` nor `@write`, so a rule built up from those categories never grants it. A credential that cannot run it still connects: identification only populates the `lib-name` field that `CLIENT LIST` and `CLIENT INFO` display, so a refusal is ignored (and logged, if you have configured logging at debug level). Grant `+client|setinfo` if you want RedisVL to appear as the connecting library there — note that this labels the connection RedisVL opens, while redis-py labels the rest of the pool as plain `redis-py`.\n\nCluster deployments need one more grant. `RedisCluster` discovers the topology with `CLUSTER SLOTS`, which is tagged `@slow` only, so a credential assembled from `+@read +@write` cannot open a clustered connection at all — redis-py reports this as `Redis Cluster cannot be connected`, with the underlying permission error chained beneath it. Grant `+cluster|slots` alongside the rules above.\n\n### Redis Cloud and Redis Software\n\nBoth manage ACLs through their own control plane rather than the `ACL SETUSER` command, so permissions are attached to roles and users instead of being set on a connection.\n\n- **Redis Cloud** provides three predefined ACL rules that cannot be edited — Full-Access, Read-Write (\"read and write commands and excludes dangerous commands\"), and Read-Only — which you assign to a data access role. See [Configure permissions with Redis ACLs](https://redis.io/docs/latest/operate/rc/security/access-control/data-access-control/configure-acls/). Custom rules use the same syntax as above.\n- **Redis Software** ships one predefined ACL, Full Access, and you define others in the Cluster Manager UI or with a [`POST /v1/redis_acls`](https://redis.io/docs/latest/operate/rs/security/access-control/create-db-roles/) request. It [does not support every `ACL` command](https://redis.io/docs/latest/operate/rs/security/access-control/redis-acl-overview/#acl-command-support), nor nested selectors, nor `(` and `)` in key patterns.\n\nBecause the predefined rules’ exact command sets are not published, confirm a credential against the database rather than inferring what its policy name implies — `ACL DRYRUN \u003cuser\u003e FT.INFO \u003cindex\u003e` answers it directly. Read the descriptions carefully before assuming you are unaffected: Read-Only allows read commands, and Read-Write \"allows read and write commands and excludes dangerous commands\", so both read as `@read`/`@write`-shaped — the shape that denies `FT.INFO` and `FT.CREATE` and wants `create_index=False`. Only Full-Access is clearly unaffected.\n\nRedis Software’s documentation uses `+@read +FT.INFO +FT.SEARCH` as an example rule, which is a good illustration: it permits querying and `index.exists()`, but not `index.create()` or index enumeration. Grant `FT.CREATE` explicitly when the application creates its own index. When the index is provisioned for the application instead, leave it out and construct with `create_index=False`.\n",
  "tags": [],
  "last_updated": "2026-09-03T16:12:40+02:00"
}