Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions docs/deployment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# Deployment

After building a Connect service, you still need to deploy it to production. This guide covers how to
use a Python application server to run a service.

## Application Servers

Connect services are standard ASGI or WSGI applications that can be run with an off-the-shelf Python
application server. Generally, any experience in running a Python application can be applied to running
Connect as-is.

### HTTP/1.1

Connect only requires HTTP/2 for bidirectional streaming RPCs - the vast majority of services can be run
using HTTP/1.1 without issue. Two servers have long been in use with HTTP/1.1 and have a proven track
record. If you are unsure what server to use, it is generally a safe bet to use one of them:

- [gunicorn](http://www.gunicorn.org/) for WSGI applications
Copy link
Contributor

@i2y i2y Nov 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe https:// is better?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess they'll be in trouble when Chrome requires it - they don't seem to support https...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I commented, I thought it connected via https, but it seems I was mistaken. sorry...

- [uvicorn](https://uvicorn.dev/) for ASGI applications

### HTTP/2

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure and forgot about daphne. Should we mention daphne as well?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately Daphne's http2 support doesn't work with bidi so I think it's confusing to add to this list. And without it, I think uvicorn is a better choice so left it out.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately Daphne's http2 support doesn't work with bidi so I think it's confusing to add to this list. And without it, I think uvicorn is a better choice so left it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I see.

If your service uses bidirectional or otherwise want to use HTTP/2, the above servers will not work.
HTTP/2 support in the Python ecosystem is still relatively young - servers known to support HTTP/2
with bidirectional streaming are:

- [granian](https://github.com/emmett-framework/granian)
- [hypercorn](https://hypercorn.readthedocs.io/en/latest/)
- [pyvoy](https://github.com/curioswitch/pyvoy)
Comment on lines +26 to +29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to improve https://github.com/i2y/tsuno so it can be on this list someday! (just a comment)


Connect has an extensive test suite to verify compatibility of connect-python with the Connect protocol.
Unfortunately, we are only able to reliably pass the suite with pyvoy, with other servers occasionally
having hung requests or stream ordering issues. pyvoy was built with connect-python in mind but is
very new and needs more time with real-world applications to verify stability.

Keep the above in mind when picking an HTTP/2 server and let us know how it goes if you give any a try.
When in doubt, if you do not use bidirectional streaming, we recommend one of the HTTP/1.1 servers.

## CORS

Connect services are standard ASGI and WSGI applications so any CORS middleware can be used to
enable it.
Comment on lines +41 to +42
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably provide a CORS interceptor, so that we don't give the false impression that users need to use Starlette for CORS support.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's ok to add an interceptor but also feel it's an HTTP concern rather than RPC and could be best left to other libraries. I changed to using asgi-cors to stress this is about using off-the-shelf middleware, not starlette's routing. What do you think?


For example, with an ASGI application using the [asgi-cors](https://pypi.org/project/asgi-cors/)
middleware:

```python
from asgi_cors import asgi_cors

from greet.v1.greet_connect import GreetServiceASGIApplication
from server import Greeter

app = GreetServiceASGIApplication(Greeter())

# app is a standard ASGI application - any middleware works as-is
app = asgi_cors(
app,
hosts=["https://acme.com"],
# POST is used for all APIs except for idempotent unary RPCs that may support GET
methods=["GET", "POST"],
headers=[
"content-type",
"connect-protocol-version",
"connect-timeout-ms",
"x-user-agent",
],
)
```