Deploying machine learning systems has a funny habit of being deceptively simple. On your laptop, everything behaves nicely. You install a library, run a command, and suddenly you have a working ML system. It feels almost unfairly easy—like you’ve unlocked a cheat code. That’s usually the moment where confidence starts to build. And then production enters the picture. Not in a dramatic “everything is on fire” way, but more like a slow realization that what you built locally was only the smallest visible part of a much larger system. Suddenly you’re not just dealing with a model—you’re dealing with dependency trees, environment mismatches, CUDA versions, GPU requirements, giant container sizes, and runtime behavior that only shows up when real traffic arrives. What started as “just running ML” quietly turns into infrastructure engineering.
This gap between local development and production is something most ML engineers eventually run into. It’s not that the tools are bad—it’s that the operational surface area grows much faster than the initial prototype suggests. DeepFace is no exception! Recently, I explored a managed approach called DeepFace.dev, which exposes facial recognition capabilities through a simple API layer built on top of DeepFace. The idea is straightforward: instead of managing the entire stack yourself, you interact with the system as a service. In this post, I’ll go through what that looks like in practice, where it fits, and what trade-offs it introduces compared to self-hosting.
🙋♂️ You may consider to enroll my top-rated machine learning course on Udemy
Vlog
The Reality of Production ML Systems
DeepFace is very straightforward to use in a local environment. Everything feels lightweight. You install it, run a function, and get results immediately. But production is a different story. Because at that point, you are no longer just running a Python library—you are effectively operating an entire machine learning stack.
Even a simple facial recognition pipeline pulls in a surprising amount of complexity:
- deep learning frameworks (e.g. tensorflow, keras)
- image processing dependencies (e.g. opencv)
- system-level libraries
- GPU drivers and compatibility layers
- model weights and runtime artifacts
And none of these components are particularly interested in cooperating if versions are slightly misaligned.
On top of that, containerization adds another layer. Docker images grow quickly, and what started as a small service can easily become something that feels heavier than expected.
In short: the system stops being about code and starts being about coordination.
Why This Becomes an Engineering Problem
The core issue is not that facial recognition is inherently complex. It is that modern ML systems come with a large operational surface area. You are basically responsible for:
- environment consistency
- dependency resolution
- hardware compatibility
- model lifecycle management
- scaling behavior
- deployment stability under load
Individually, these problems are manageable. Together, they become a full-time engineering discipline. And this is usually the point where “quick prototype” timelines start quietly expanding.
DeepFace Cloud
This is exactly the gap that platforms like DeepFace.dev are trying to reduce. Instead of managing infrastructure, the system exposes core functionality through an API. In practice, this means two main operations:
- generating facial embeddings
- comparing faces
From a developer perspective, the mental model becomes much simpler: You send data and you get results. Everything else disappears behind the API boundary.
Represent Endpoint
The represent endpoint converts a facial image into a numerical embedding(s). In simpler terms: it turns a face into a vector representation that can be compared mathematically.
curl --request POST \ --url https://api.deepface.dev/represent \ --header "Authorization: Bearer $DEEPFACE_CLOUD_KEY" \ --form "img=@image.jpg" \ --form "model_name=Facenet"
No local model setup. No GPU configuration. No dependency management. It’s just an HTTP request.
Verify Endpoint
The verify endpoint compares two faces and determines whether they belong to the same person.
curl --request POST \ --url https://api.deepface.dev/verify \ --header "Authorization: Bearer $DEEPFACE_CLOUD_KEY" \ --form "img1=@image1.jpg" \ --form "img2=@image2.jpg" \ --form "model_name=Facenet"
And the response will be like below for true positive pairs
{
"verified": true
}
Or it will be like below for true negative pairs
{
"verified": false
}
Which is exactly what you want from a system like this—no philosophical confusion about identity.
Licensing Considerations
One important detail in DeepFace is licensing. Some pre-trained models cannot be used freely in commercial environments. Because of this, certain models are excluded from the platform. For example, VGG-Face – the default one in DeepFace – is not included.
Who Is This For and Who Isn’t This For?
This kind of managed approach makes the most sense for:
- startups building most valuable products (MVPs)
- teams without GPU infrastructure
- rapid prototyping workflows
- serverless or lightweight backend systems
- developers who prefer not to maintain ML infrastructure
On the other hand, self-hosting is still the right choice when you need:
- full infrastructure control
- strict privacy requirements
- custom deployment strategies
- deep performance tuning
- large-scale cost optimization
It is not a replacement model—it is a trade-off.
Attribution & Context
It’s worth clarifying the relationship between the tools mentioned in this post.
Firstly, DeepFace is an open-source project that I created and still maintain. It is the core library behind many of the examples discussed here.
On the other hand, DeepFace.dev (often referred to as DeepFace Cloud) is a separate managed service developed by Tech Local – a South African tech team. This platform provides hosted APIs built around facial recognition capabilities.
While the cloud service exposes functionality inspired by DeepFace workflows, it is not my product and is independently operated. Still, they cited my DeepFace repo in their official website.
Conclusion
The journey from local experimentation to production is often where machine learning projects reveal their true nature. On the surface, facial recognition looks like a straightforward problem: you compare images, get a score, and move on. But once you start thinking about real-world deployment, the problem quietly expands into something much larger—one that includes infrastructure, scaling, dependency management, and all the operational details that don’t show up in notebooks.
This is exactly the gap managed solutions like DeepFace.dev are trying to address. By exposing functionality from DeepFace through a simple API layer, they remove much of the operational burden and let developers focus on building features rather than maintaining infrastructure. Of course, this does not make self-hosting obsolete. In many cases, running your own stack is still the right choice—especially when you need full control, strict privacy guarantees, or deep optimization at scale. But it does change the default trade-off. What used to be “obviously self-host everything” is now more of a spectrum between control and convenience. If nothing else, this shift is worth paying attention to. Because in practice, most engineering decisions are not about what is possible—they are about what is worth maintaining over time. And sometimes, the most productive infrastructure decision is simply deciding not to own all of it yourself.
Support this blog financially if you do like!
