langchain-serve
Enrichment pending⚡ Langchain apps in production using Jina & FastAPI
GraphCanon updated today · GitHub synced today
Trust & integrity
Full report- Maintenance
- Archived (1025d since push)
- As of today · Source: github_public_v1
- Provenance
- Not a fork · Organization account
- As of today · Source: github_public_v1
- Security (OSV)
- No criticals
- As of today · Source: osv@v1
Public GitHub metadata and optional OSV dependency scans. Signals, not a guarantee. Trust methodology.
Overview
⚡ Langchain apps in production using Jina & FastAPI
Capability facts
- Languages
- python
Source: github.language+pyproject.toml · Jul 11, 2026
Categories
Compatibility
Sourced claims from the README excerpt - not unsourced marketing copy.
Tags
README
🏠 Self-host LLM Apps with Docker Compose or Kubernetes
- 🚀 Export your apps as Kubernetes or Docker Compose YAMLs with single command.
- 👉
lc-serve export app --kind <kubernetes/docker-compose> --path . - 📦 Deploy your app on your own internal infrastructure with your own security policies.
- 📞 Talk to us if you need all the features of Jina AI Cloud on your own infrastructure.
🗝️ Using Secrets during Deployment
You can use secrets during app deployment by passing a secrets file to deployment with the --secrets flag. The secrets file should be a .env file containing the secrets.
lcserve deploy jcloud app --secrets .env
Show details
Let's take an example of a simple app that uses OPENAI_API_KEY stored as secrets.
This app directory contains the following files:
.
├── main.py # The app
├── jcloud.yml # JCloud deployment config file
├── README.md # This README file
├── requirements.txt # The requirements file for the app
└── secrets.env # The secrets file containing the redis credentials
Note
secret.envin this directory is a dummy file. You should replace it with your own secrets after creating a Redis instance. (For example with Upstash), such as:
OPENAI_API_KEY=sk-xxx
main.py will look like:
---
## 💰 Pricing
Applications hosted on JCloud are priced in two categories:
**Base credits**
- Base credits are charged to ensure high availability for your application by maintaining at least one instance running continuously, ready to handle incoming requests. If you wish to stop the serving application, you can either remove the app completely or put it on pause, the latter allows you to resume the app serving based on persisted configurations (refer to [`lc-serve` CLI section](#-lc-serve-cli) for more information). Both options will halt the consumption of credits.
- Actual credits charged for base credits are calculated based on the [instance type as defined by Jina AI Cloud](https://docs.jina.ai/concepts/jcloud/configuration/#cpu-tiers).
- By default, instance type `C3` is used with a minimum of 1 instance and [Amazon EFS](https://aws.amazon.com/efs/) disk of size 1G, which means that if your application is served on JCloud, you will be charged ~10 credits per hour.
- You can change the instance type and the minimum number of instances by providing a YAML configuration file using the `--config` option. For example, if you want to use instance type `C4` with a minimum of 0 replicas, and 2G EFS disk, you can provide the following configuration file:
```yaml
instance: C4
autoscale_min: 0
disk_size: 2G
Serving credits
- Serving credits are charged when your application is actively serving incoming requests.
- Actual credits charged for serving credits are calculated based on the credits for the instance type multiplied by the duration for which your application serves requests.
- You are charged for each second your application is serving requests.
Total credits charged = Base credits + Serving credits. (Jina AI Cloud defines each credit as €0.005)
JCloud deployment failed at pushing image to Jina Hubble, what should I do?
Expand
Please use --verbose and retry to get more information. If you are operating on computer with arm64 arch, please retry with --platform linux/amd64 so the image can be built correctly.