You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update defaults for --hostname and --local-executor (#905)
* do it
* Change defaults
* integrate with ci/cd updates
* Fix ci
* Add dockerfile `SKIP_OPENSSL` option which will allow us to build container without openssl
* Skip openssl for latest tag, add another openssl tag for images with openssl support
* Push separate openssl image to GHCR for every PR
- Plugin API is currently in *development phase*. Expect breaking changes. See [Deploying proxy.py in production](#deploying-proxypy-in-production) on how to ensure reliability across code changes.
- [Inspect, Monitor, Control and Configure](#inspect-traffic) `proxy.py` at runtime
194
209
- [Chrome DevTools Protocol](#chrome-devtools-protocol) support
195
-
- Extend dashboard using plugins
196
-
- Dashboard is currently in development phase, expect breaking changes
210
+
- Extend dashboard frontend using `typescript` based [plugins](https://github.com/abhinavsingh/proxy.py/tree/develop/dashboard/src/plugins)
211
+
- Dashboard is currently in *development phase* Expect breaking changes.
197
212
- Secure
198
213
- Enable end-to-end encryption between clients and `proxy.py`
199
214
- See [End-to-End Encryption](#end-to-end-encryption)
200
215
- Private
201
-
- Everyone deserves privacy. Browse with malware and adult content protection
216
+
- Protection against DNS based traffic blockers
217
+
- Browse with malware and adult content protection enabled
202
218
- See [DNS-over-HTTPS](#cloudflarednsresolverplugin)
203
219
- Man-In-The-Middle
204
220
- Can decrypt TLS traffic between clients and upstream servers
205
221
- See [TLS Interception](#tls-interception)
206
-
- Supported proxy protocols
222
+
- Supported http protocols for proxy requests
207
223
- `http(s)`
208
224
- `http1`
209
225
- `http1.1` with pipeline
@@ -226,6 +242,8 @@
226
242
227
243
# Install
228
244
245
+
Consult [Deploying proxy.py in production](#deploying-proxypy-in-production) when deploying production grade applications using `proxy.py`.
246
+
229
247
## Using PIP
230
248
231
249
### Stable Version with PIP
@@ -1738,6 +1756,96 @@ Now point your CDT instance to `ws://localhost:8899/devtools`.
1738
1756
1739
1757
# Frequently Asked Questions
1740
1758
1759
+
## Deploying proxy.py in production
1760
+
1761
+
Listed below are a few strategies for using `proxy.py` in your private/production/corporate projects.
1762
+
1763
+
### What not to do?
1764
+
1765
+
> You MUST `avoid forking` the repository *"just"* to put your plugin code in `proxy/plugin` directory. Forking is recommended workflow for project contributors, NOT for project users.
1766
+
1767
+
Instead, use one of the suggested approaches from below. Then load your plugins using `--plugin`, `--plugins` flags or `plugin` kwargs.
1768
+
1769
+
### Via Requirements
1770
+
1771
+
It is *highly* recommended that you use `proxy.py` via `requirements.txt` or similar dependency management setups. This will allow you to take advantages of regular performance updates, bug fixes, security patches and other improvements happening in the `proxy.py` ecosystem. Example:
1772
+
1773
+
1. Use `--pre` option to depend upon last `pre-release`
1774
+
1775
+
```console
1776
+
❯ pip install proxy.py --pre
1777
+
```
1778
+
1779
+
Pre-releases are similar to depending upon `develop` branch code, just that pre-releases may not point to the `HEAD`. This could happen because pre-releases are NOT made available on `PyPi` after every PR merge.
1780
+
1781
+
2. Use `TestPyPi` with `--pre` option to depend upon `develop` branch code
A pre-release is made available on `TestPyPi` after every PR merge.
1788
+
1789
+
3. Use last `stable` release code
1790
+
1791
+
As usual, simply use:
1792
+
1793
+
```console
1794
+
❯ pip install proxy.py
1795
+
```
1796
+
1797
+
### Via Docker Container
1798
+
1799
+
If you are into deploying containers, then simply build your image from base `proxy.py` container images.
1800
+
1801
+
1. Use `GHCR` to build from `develop` branch code:
1802
+
1803
+
```console
1804
+
FROM ghcr.io/abhinavsingh/proxy.py:latest as base
1805
+
```
1806
+
1807
+
*PS: I use GHCR latest for several production level projects*
1808
+
1809
+
2. Use `DockerHub` to build from last `stable` release code:
1810
+
1811
+
```console
1812
+
FROM abhinavsingh/proxy.py:latest as base
1813
+
```
1814
+
1815
+
PS: IMHO, container based strategy is *the best approach* and the only strategy that *I use myself*.
1816
+
1817
+
### Integrate your CI/CD with proxy.py
1818
+
1819
+
*Hey, but you keep making breaking changes in the develop branch.*
1820
+
1821
+
I hear you. And hence, for your production grade applications, you *MUST* integrate application CI/CD with `proxy.py`. You must make sure that your application builds and passes its tests for every PR merge into the `proxy.py` upstream repo.
1822
+
1823
+
If your application repository is public, in certain scenarios, PR authors may send patch PRs for all dependents to maintain backward incompatibility and green CI/CD.
1824
+
1825
+
CI/CD integration ensure your app continues to build with latest `proxy.py` code. Depending upon where you host your code, use the strategy listed below:
1826
+
1827
+
- GitHub
1828
+
1829
+
TBD
1830
+
1831
+
- Google Cloud Build
1832
+
1833
+
TBD
1834
+
1835
+
- AWS
1836
+
1837
+
TBD
1838
+
1839
+
- Azure
1840
+
1841
+
TBD
1842
+
1843
+
- Others
1844
+
1845
+
TBD
1846
+
1847
+
> At some stage, we'll deprecate `master` branch segregation and simply maintain a `develop` branch. As dependents can maintain stability via CI/CD integrations. Currently, it's hard for a production grade project to blindly depend upon `develop` branch.
1848
+
1741
1849
## Stable vs Develop
1742
1850
1743
1851
- `master` branch contains latest `stable` code and is available via `PyPi` repository and `Docker` containers via `docker.io` and `ghcr.io` registries.
0 commit comments