Why vLLM on FIPS-enabled hosts needs a deliberate setup
Running vLLM on a FIPS-enabled Linux host requires deliberate configuration, and some of its traffic needs an external FIPS-validated layer. The engine does not cover every network path on its own, so the team must decide which connections are protected, by which component, before go-live. The starting point is knowing what FIPS mode changes on the host and where vLLM and its dependencies make their own cryptographic choices. Those choices determine what the auditor will ask to see and what your team must configure, document and test.
FIPS mode typically affects three layers: the host crypto policy that the operating system applies to system libraries, the cryptographic libraries that Python packages load, and the TLS settings used by any service that terminates encrypted connections. vLLM also has package-level choices to check. The blake3 package is installed by default but is only used when the multimodal hasher is set to blake3, and xxhash is used only when an xxhash prefix cache algorithm is selected. Confirm which of these paths are active in your configuration, and confirm whether any dependency bundles its own crypto instead of using the host libraries.
A single-node deployment mainly needs the API endpoint and any proxy in front of it to meet your TLS requirements, which is a bounded problem. Multi-node deployments add a larger one. The vLLM security documentation states that communication between nodes is insecure by default, and its PyTorch distributed, KV cache transfer and data parallel channels do not encrypt traffic. Network isolation alone does not satisfy a FIPS requirement for that traffic, so you need an external layer such as an mTLS sidecar or IPsec. Regulated data in prompts, responses or cached content raises the stakes for both cases and should trigger a full review of this page's controls.
DeployOpen plans and implements this setup inside your infrastructure, then prepares the configuration, the test results and the evidence your assessors will request. DeployOpen does not issue certifications, attestations or audit reports, and validation of the cryptographic modules you use must be confirmed against the module vendor's validation records. Before engaging, ask for a written scope that lists the nodes, traffic paths, encryption layer, host images and the evidence each deliverable will contain. Your compliance lead should confirm which assessor will review the result and which validation records they will accept.
Configuration options for a FIPS host and when each fits
This table compares the configuration decisions that shape the FIPS posture of a vLLM host, showing what each one controls, when it fits and what to confirm before choosing it. Read it as a checklist: most hosts need the endpoint restrictions and protection for in-transit traffic, while the hash and cache algorithm choices depend on what your assessor accepts. The main takeaway is that the API key alone does not restrict access, and inter-node traffic needs a protection layer outside vLLM.
| Option | What it controls | When it fits | What to confirm |
|---|---|---|---|
| API key (--api-key) | Requires a key on the /v1, /v2, /inference and /cohere endpoints only. | Fits hosts where clients call those endpoints directly, as one layer among several. | That /invocations, /pause, /resume, /abort_requests, /metrics and /health are unreachable to users. |
| Reverse proxy allowlist | Passes only the endpoints meant for users and blocks every other path. | Fits every host that serves users, since the security docs advise against relying on the key alone. | The allowlist matches the endpoints in the security docs, and blocked paths are retested after each upgrade. |
| mTLS sidecar or IPsec | Encrypts inter-node traffic, including PyTorch distributed, KV cache transfer and data parallel channels. | Fits any multi-node run or any deployment that moves KV cache between nodes, because vLLM does not encrypt these channels. | The FIPS validation status of the chosen module, and which ports and channels it covers. |
| Blake3 multimodal hasher | Sets blake3 as the hash for multimodal inputs. The package is installed by default but used only when selected. | Fits multimodal workloads that intentionally select it and whose assessor accepts that hash. | Whether the multimodal hasher is set to blake3, and whether your FIPS policy accepts that algorithm for this use. |
| xxhash prefix cache algorithm | Selects xxhash for prefix caching. It is optional and used only when this algorithm is chosen. | Fits teams that have reviewed it and chose it on purpose. Otherwise leave it unselected. | Whether your assessor accepts this hash for prefix caching on a FIPS host, and that it is not selected by default. |
| TLS termination and cipher policy | Terminates client TLS at the reverse proxy and sets the accepted protocol and cipher policy. | Fits any network-exposed API, since the proxy is where this design sets the policy. | Which protocol versions and cipher suites your FIPS module permits, and the proxy's validation status. |
How hash algorithm settings affect a FIPS review
A FIPS review turns on which hash algorithms actually run in your configuration, and the packages in the image are only part of that picture. The vLLM security documentation states that the blake3 package is installed by default but is used only when the multimodal hasher is set to blake3. It also states that xxhash is optional and is used only when an xxhash prefix cache algorithm is selected. The hashing behavior of a host therefore depends on two settings, and the default install alone does not tell a reviewer what runs. Treat each setting as a decision with an owner, a value and a recorded reason. This matters most on hosts where the reviewer will test the stack that runs in production.
For each host profile, record the multimodal hasher value and the prefix cache algorithm in use. Include values set through launch arguments, configuration files and environment variables, because any one of them can override the others. If your workloads do not use multimodal inputs or do not need the xxhash option, decide whether the unselected hasher is needed at all. Then ask your platform team whether its package can be removed from the image without breaking the build. Where the algorithm choice affects cache behavior, have the engineering owner confirm the change in a test environment before it reaches production. A setting that is changed later without a test is a common source of review findings.
Presence and use are separate questions, and the reviewer will ask both. A package can be installed and never called, yet still be loaded when Python imports a module that references it. Confirm which hash libraries load at import time in your runtime. One practical method is to inspect the loaded modules of a running server process after startup, then after test requests that exercise each hasher setting. Ask the vLLM maintainers or your own engineers which import paths reach these libraries in the release you run. Repeat the check after each upgrade, since vLLM ships new minor releases about every two weeks and import paths may change between them.
Document the outcome as part of the FIPS evidence. For each host profile, record the active hasher and prefix cache choice, the default values, the packages present in the image, the libraries loaded at import time, the test method and the date it was run. For each hash library, state whether it is present and whether it is used, and attach the evidence for each answer. Keep this record under change control so that any change to a hash setting triggers a new check. DeployOpen can prepare this evidence, but conclusions about it belong to your assessor or certification body.
Which dependencies bring their own crypto into a FIPS host
A vLLM deployment on a FIPS-enabled host inherits crypto from every layer beneath it, and not all of that crypto comes from the host. The cards below cover the layers a reviewer will ask about, the question to answer for each, and where the answer has to come from.
Python environment and wheels
vLLM and its Python dependencies are installed as wheels or source packages, and some of them include compiled extensions with their own cryptographic code. For each package in the environment, ask whether it calls the host OpenSSL or Python ssl module, whether it ships a bundled copy of a crypto library, and whether that copy is covered by any validation. Generate the package list from the actual image or virtual environment, then get the crypto behavior for each entry from its maintainer.
CUDA, ROCm or other accelerator stack
The GPU runtime and its math libraries are usually installed as vendor packages or inside the base image, and they can carry their own cryptographic components or depend on specific system libraries. Confirm which accelerator stack the chosen vLLM build targets, then ask the GPU vendor whether its runtime calls host crypto libraries, ships its own, and whether any module is validated. Record the versions in the bill of materials, since a change to the driver or runtime can change the answer.
Container base image and OpenSSL
If vLLM runs from a container, the base image supplies the OpenSSL or equivalent library that the Python runtime and many wheels link against. The question is whether the image's crypto library is the one the host's FIPS mode governs, or whether the image carries a separate copy. Check the image's package inventory and library linkage in the built image, not only in the Dockerfile, and confirm the FIPS status of that library with its distributor.
Third-party hardware plugins
vLLM supports additional accelerators through third-party hardware plugins that live outside the main repository, so their code and dependencies are not covered by the vLLM project's documentation. Each plugin can add its own crypto libraries, network clients or telemetry components. Ask the plugin maintainer for its dependency list, its crypto behavior under FIPS mode, and any validation it claims, and treat a missing answer as an open risk rather than a pass.
Bill of materials for the actual image
Vendor statements apply to a specific product version, so a reviewer needs a bill of materials built from the image or environment that will run in production. The bill should list every Python package, system library, accelerator component and plugin with its version and the crypto library each one links against. Use it as the single record that each vendor answer is mapped to, and regenerate it whenever the image or a dependency version changes.
Ownership of each answer
Each dependency's crypto behavior and validation status must be stated by the party that owns it: the package maintainer, the accelerator vendor, the base image distributor or the plugin author. DeployOpen can help collect those answers, check the built image against them and record the evidence, but the statements themselves come from the vendors. Ask each vendor to put its answer in writing with the version it covers, and keep those statements with the bill of materials.
How to set up vLLM on a FIPS-enabled host, step by step
This sequence takes a FIPS-enabled Linux host from inventory to a tested vLLM deployment. Each step ends with a check that produces a record for security and compliance reviewers. The order matters because the encryption layer and proxy allowlist depend on the host and dependency baseline set earlier.
Inventory the host, image and Python dependencies
The engineer responsible for the host records the operating system and kernel version, the GPU driver and accelerator stack, the vLLM image or wheel version, and every Python package in the environment. Pin each item to a specific version and keep the list in the change record. Check whether the blake3 package, which vLLM installs by default, and the optional xxhash package are present, because each brings its own cryptographic code that must be reviewed. Confirm the vLLM version against the project's release history before pinning it. For air-gapped hosts, stage model weights and any chat template file inside the boundary, since models must provide a chat template or receive one through --chat-template. Add --enable-offline-docs if the API docs must be served without internet access. Done when the inventory can be rebuilt from the record alone and every package has a version and a source.
Confirm FIPS mode and record the crypto policy
The platform team checks that the host kernel runs in FIPS mode and records the system crypto policy that governs TLS and related services. On Linux, the flag at /proc/sys/crypto/fips_enabled should read 1. Confirm with your distribution's documentation which command reports the active policy, then save that output to the host record. Check that the Python interpreter and the libraries vLLM loads use the system crypto libraries the policy governs, and list any package that bundles its own cryptography, since it sits outside that policy and needs a documented decision. Done when the recorded output shows FIPS mode enabled, the policy name matches your approved baseline, and every bundled cryptographic library is listed.
Decide and document the hash settings
Decide which hash algorithms vLLM uses and write the decision down before the service starts. The blake3 package is installed by default but is used only when the multimodal hasher is set to blake3. The xxhash package is optional and is used only when an xxhash prefix cache algorithm is selected. Choose the multimodal hasher and prefix cache algorithm that your FIPS policy allows, and record each flag and its value in the deployment configuration. Ask your security team to confirm in writing that each selected algorithm is on the approved list. After startup, check the running configuration against the document to confirm the settings took effect. Done when the document names each hash setting, its value, the approver and the date of approval.
Place nodes and select the external encryption layer
Map every node in a multi-node deployment, including which host runs each role and which network segment each one uses. vLLM's security documentation states that communication between nodes is insecure by default, without authorization or encryption, and that its PyTorch distributed, KV cache transfer and data parallel channels do not encrypt traffic. Choose an external layer such as an mTLS sidecar or IPsec for these channels, and ask your security team to confirm that its cryptographic module is FIPS-validated and runs in FIPS mode. Isolating nodes on a dedicated network is required, but on its own it does not satisfy this requirement. Done when a diagram shows each node, each channel and the encryption layer that protects it.
Put a reverse proxy in front with an allowlist
Place a reverse proxy in front of the vLLM server and bind vLLM to a private interface so user traffic reaches it only through the proxy. Allow only the endpoints your applications call, such as the OpenAI-compatible completions, chat, responses and embeddings paths, and deny every other path by default. Set the TLS protocol versions and cipher suites at the proxy, using the list your FIPS policy approves, and keep that configuration under version control. Test from a user network by requesting an allowed path, a denied path and a weak TLS handshake. Done when disallowed paths return a denial, only the approved TLS parameters are accepted and the proxy configuration is recorded with its approval.
Configure --api-key as one control only
Set the --api-key option on vLLM and treat it as one control among several. The option protects the /v1, /v2, /inference and /cohere endpoints, but it does not protect /invocations, /pause, /resume, /abort_requests, /metrics or /health, and the vLLM docs warn against relying on it alone. Store the key in your approved secrets store, set a rotation schedule that your policy defines, and confirm the proxy still enforces the allowlist when the key is valid. Test by sending a request without a key to a protected endpoint, expecting rejection, and a request with the key to an allowed endpoint, expecting success. Done when both tests give the expected result and the key appears in neither service logs nor shell history.
Verify metrics and health are unreachable from user networks
From a host on each user network, request /metrics and /health through the proxy and directly against the vLLM port. Each request should fail, because the proxy allowlist excludes these paths and the API key does not protect them. If your monitoring stack scrapes /metrics, confirm that the scraper on its own network can still reach it and that no other source can. Record the source address, path, response and time for each test. Done when every user network returns a denial for both paths and the monitoring source is the only permitted client, with the results saved to the host record.
Test each channel and retain the evidence
Test every channel separately: the user API through the proxy, inter-node traffic in multi-node runs, KV cache transfer if it is enabled and data parallel traffic if it is used. For each channel, capture traffic in a test segment and confirm that it is wrapped by the external encryption layer, with no plaintext application payload visible. Confirm the proxy TLS parameters and the API key behavior still match the earlier records. Repeat the full test after every configuration change and every vLLM version upgrade. Done when a dated test record lists each channel, the capture method and the result, and a reviewer has signed off on it.
Which vLLM endpoints must stay out of user reach
The vLLM API server exposes more than the endpoints users need, and the --api-key option covers only part of that surface. The cards below separate user-facing endpoints from administrative and diagnostic ones, and set out what a reverse proxy and network controls must block before a FIPS-enabled host accepts traffic.
Why --api-key is not enough
The --api-key option protects the /v1, /v2, /inference and /cohere endpoints, but it does not cover /invocations, /pause, /resume, /abort_requests, /metrics or /health. The vLLM security documentation warns against relying on it alone. Before go-live, confirm with your own tests which paths return a response without a key on your exact vLLM version.
Allowlist user-facing endpoints at a proxy
The vLLM security documentation recommends a reverse proxy that allowlists only the endpoints meant for users. On a FIPS-enabled host, the proxy is also the place to terminate TLS with approved cipher settings and enforce authentication before requests reach the engine. Deny everything by default and add each inference path, such as /v1/chat/completions, by name.
Restrict pause, resume and abort to operators
The /pause, /resume and /abort_requests endpoints change how the running engine handles work, so they belong on an operator-only path. Block them at the proxy for every client that is not an administrator, and bind any operator access to named identities through your identity provider. Test that a standard application key cannot reach these paths.
Keep /metrics away from end users
The /metrics endpoint publishes Prometheus-format data covering request counts, token throughput, latency histograms and KV cache use. That information reveals load patterns and capacity limits to anyone who can read it. Expose it only to your monitoring network, and confirm that your scraper reaches it through an internal path rather than the public listener.
Decide on /health and /invocations
The /health endpoint is needed by load balancers and orchestrators, but it is not a user API, and /invocations is not covered by --api-key either. Decide whether each is needed at all in your topology, allow /health only from the platform's probe sources, and remove /invocations from the proxy allowlist unless a confirmed client requires it.
Verify exposure after every upgrade
Endpoint sets change between vLLM releases, and new routes may appear without any change to your proxy. Keep a test suite that requests every known route with and without credentials, and rerun it after each version change. Record the results as part of your change evidence so that the allowlist is checked against the release you actually run.
Keeping a FIPS-enabled vLLM host configured after release changes
Each vLLM upgrade can change the settings that matter for a FIPS-enabled host, so the crypto-relevant configuration, the dependency set and the endpoint list need to be re-checked every time the version moves. vLLM ships new minor releases about every two weeks. The GitHub releases page lists v0.28.0 on August 26, v0.29.0 on September 9, v0.30.0 on September 22 and v0.31.0 on October 5, 2026, which is four minor releases in about six weeks. A host that was reviewed once at deployment can drift quickly if nobody owns the review after each release. Start the routine by pinning the exact vLLM version in the image tag or package lock, so that no host picks up a new release by accident. Then rebuild the bill of materials for that version. Record the Python packages and their versions, and note which hashing libraries are present. The blake3 package is installed by default but only used when the multimodal hasher is set to blake3. The xxhash package is optional and only used when an xxhash prefix cache algorithm is selected. Confirm for each release whether either default has changed, and document which algorithm your configuration actually selects.
Next, re-run the traffic and endpoint checks against the new version. Confirm that the reverse proxy still allowlists only the OpenAI-compatible endpoints meant for users, such as /v1/completions, /v1/chat/completions, /v1/responses and /v1/embeddings. Confirm that the endpoints the --api-key option does not protect, including /metrics, /health, /pause, /resume and /abort_requests, remain unreachable from user networks. A new release can add or rename routes, so compare the live endpoint list with the approved list rather than assuming it is unchanged. Also verify the transport protections. The vLLM security documentation states that PyTorch distributed, KV cache transfer and data parallel channels do not encrypt traffic. Your external layer, such as an mTLS sidecar or IPsec, must still wrap those channels after the upgrade. Capture a test showing that inter-node traffic is protected, and confirm that the TLS cipher restrictions on the proxy still apply to the new build. Network isolation alone does not satisfy this requirement, so do not treat a clean isolation test as evidence of encryption.
Finally, record every change in a dated log entry for each release. The entry should name the old and new version, the dependency differences, the configuration differences (hashing settings, cipher restrictions, proxy rules and sidecar versions), the test results, and the person who approved the change. Include a decision for each release: adopt it, defer it, or hold it until a specific issue is resolved. Deferral is a valid outcome, but it should be written down with a review date so the host does not fall behind without anyone noticing. The upgrade mechanics, including rollback steps and rollout order, are covered in the vLLM upgrades group. This section covers the review that happens around each upgrade. Ask your compliance lead which evidence they need from each review, since that record is what an assessor will ask to see. DeployOpen can prepare the release review routine and its evidence as part of a fixed-scope engagement or a retainer, but the assessment itself is performed by an independent auditor.
What to confirm in your environment before claiming FIPS alignment
FIPS alignment for vLLM depends on several layers working together: the server's own transport settings, the crypto libraries it pulls in, the external layer that protects traffic between nodes, and the accelerator stack underneath. Each card below is a item your team must confirm for the exact versions it deploys, since none of them is settled by the vLLM project alone.
TLS settings the server exposes
Start by listing which TLS options the vLLM API server and any reverse proxy in front of it actually expose, including protocol versions and certificate handling. Confirm in the vLLM documentation for your pinned release which settings are configurable at all. Record the result per listener, because the proxy and the server may negotiate different parameters.
Restriction of the cipher policy
Determine whether the cipher policy can be restricted in the version you deploy, and to which suites. If the release offers no such control, the host's FIPS cipher policy may not reach the vLLM listener at all. Confirm this with the vLLM docs for the pinned release and test the negotiated suites from a client on the same network path.
Crypto modules in the host and dependencies
Inventory every library that performs cryptography, including the Python runtime, OpenSSL, and packages that bundle their own primitives. vLLM notes that blake3 is installed by default and used only when the multimodal hasher selects it, and that xxhash is used only for a specific prefix cache algorithm. For each module, ask the vendor for its validation status and the exact validated version.
External mTLS or IPsec layer validation
vLLM's PyTorch distributed, KV cache transfer and data parallel channels do not encrypt traffic, so the external layer carries that obligation. Confirm whether the mTLS sidecar or IPsec implementation you choose uses a FIPS-validated cryptographic module, and whether that module is enabled in the mode you run. Network isolation alone does not satisfy this requirement.
GPU driver and accelerator stack
Document the GPU vendor, driver version, CUDA or ROCm release and any kernel modules in use, then check whether each component's cryptographic behavior and signing mechanism are compatible with your FIPS host configuration. Driver and container runtime updates can change this, so tie the confirmation to the exact build you run. Ask the GPU vendor for written guidance on their crypto usage.
Evidence for assessors
Assemble the configuration files, dependency lists, pinned versions and test results that show what the deployment does. DeployOpen prepares configuration and evidence for your review, but independent auditors and certification bodies decide what any report or certification means. Do not describe the deployment as FIPS validated or certified unless an accredited body has said so for your scope.
What vLLM on FIPS-enabled hosts costs and what it needs from your team
What drives the cost of a FIPS-enabled vLLM setup?
The cost depends on scope, mainly the number of nodes, the accelerators in each node, and how many dependencies need a crypto review. The external encryption layer for inter-node traffic adds design, build and testing work, and the evidence your assessor expects adds documentation work. vLLM itself has no paid edition and no license fee, so the money goes to accelerator capacity, surrounding infrastructure, implementation and the people who operate the system. Ask any quote to break out each of these components, state what is one-time and what recurs, and list which items are excluded.
How long does a FIPS-enabled vLLM implementation take?
Duration is set by the scope, so no reliable figure exists until the scope is written down. The biggest drivers are the number of nodes, whether multi-node parallelism is in use, how many images and dependencies must be inventoried, the choice and rollout of the external encryption layer, and how quickly your team can provide host access and reviews. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the schedule, its assumptions and the client dependencies that could move it.
Does vLLM have a license fee for FIPS deployments?
No. vLLM is licensed under Apache-2.0 according to its GitHub repository, and it has no paid edition. Your costs come from GPU or other accelerator capacity, the infrastructure around them, implementation work, and operations staff. The external encryption layer that FIPS environments need, such as an mTLS sidecar or IPsec, may carry its own licensing or support terms, and the same is true for any operating system, Python or dependency packages you standardize on. Confirm those terms with each vendor before you finalize the budget.
What does my team need to provide for a vLLM FIPS engagement?
Your team needs to provide four things: host access to the nodes and the staging environment, an image and package inventory covering the vLLM container or Python environment and every dependency, network diagrams that show node placement, the internal ports and the paths users reach, and a named owner who makes decisions and approves changes. Your team should also be ready to supply the list of endpoints users need, since the vLLM docs recommend a reverse proxy that allowlists only those endpoints. Missing inputs usually extend the schedule, so confirm them before the kickoff.
Can our own team set up vLLM on FIPS-enabled hosts without outside help?
Yes, a capable team can, provided it works from a written checklist and has an independent reviewer who did not build the system. The checklist should cover hash algorithm settings, TLS cipher restrictions, the crypto behavior of each dependency, and external protection for inter-node traffic, because the vLLM security docs state that network isolation alone does not meet that requirement. A reviewer catches gaps that the builders miss. DeployOpen can prepare systems, controls and evidence, but it does not issue audit reports, attestations or certifications, so an independent auditor or certification body still makes that determination.
What is one-time and what recurs after a FIPS vLLM deployment?
One-time work includes the architecture, the initial build, the first dependency inventory, the external encryption layer rollout and the first set of evidence. Recurring work is driven by change. vLLM ships new minor releases about every two weeks, for example v0.31.0 on October 5, 2026, and each upgrade can change dependencies, defaults or crypto-relevant behavior, so it needs re-verification. Certificate rotation, dependency updates, log and metrics review, and access changes also recur. Ask any quote to separate these categories, and ask whether ongoing support, upgrades and testing will be covered by a retainer.
What stays with our team after a vLLM FIPS build is handed over?
Your team keeps ownership of the running system, its change approvals and its evidence set. In practice that means operating the vLLM service, applying upgrades after they have been verified, rotating certificates and keys, watching the Prometheus-format metrics exposed at /metrics, and keeping the inventory current when a dependency changes. It also means keeping the proxy allowlist correct and knowing which internal ports must stay closed. Ask for a handover document that names each recurring task, its owner and its frequency, and confirm which of those tasks a retainer would take over.
How DeployOpen scopes and delivers a FIPS-enabled vLLM setup
DeployOpen plans and delivers self-hosted vLLM inside infrastructure you control, including its FIPS-enabled Linux hosts. We start from the crypto settings, dependencies and network paths that matter for your boundary, then build, test, document and hand over the result. Ongoing support is available as a retainer.
How we scope
- The written scope lists the FIPS-enabled host images, vLLM version and accelerator targets covered by the engagement.
- We map every hash, TLS and crypto dependency vLLM loads, including optional packages such as blake3 and xxhash.
- The scope names which inter-node and KV transfer paths need an external FIPS-validated encryption layer.
How we build
- We configure hash algorithm settings and TLS cipher restrictions to match your FIPS policy on the target hosts.
- We place an mTLS sidecar or IPsec tunnel in front of multi-node traffic that vLLM does not encrypt itself.
- We test the build by checking each endpoint, cipher negotiation and dependency path against the documented baseline.
How we hand over
- You receive configuration files, build records and a runbook describing each crypto setting and why it was chosen.
- The handover pack lists the dependencies that bundle their own crypto, with the verification steps your team should repeat.
- We walk your engineers through host checks, pinning decisions and what to revalidate before any vLLM version change.
How we support
- Retainer support covers reviewing new vLLM releases against the FIPS configuration before your team upgrades.
- We re-run the crypto and transport checks after host patches, dependency updates or changes to the proxy layer.
- Your compliance team receives evidence of configuration state for the auditors you choose, which DeployOpen does not certify.
