| .github | ||
| backend | ||
| core | ||
| ddnsserver | ||
| doc | ||
| frontend | ||
| himhip | ||
| nginx | ||
| onionhat/src | ||
| plugins | ||
| schemas | ||
| setup | ||
| sshserver | ||
| vpn | ||
| .gitignore | ||
| .gitmodules | ||
| .npmrc | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| crowdin.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| flyingfish.spdx.json | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
| SECURITY.md | ||
Flyingfish
FlyingFish is a reverse proxy manager with own WebUI, DNS server, SSH server, DynDNS, UPNP support, Lets Encrypt and much more.
Make your services available easily, quickly and securely.
In the classic sense, FlyingFish is a nginx manager. But the way the nginx server is combined with other services is different! The FlyingFish is structured in part service, which automates many processes through an internal database or API communication.
Quick setup
Read the Documentation quick setup
Release
Current work
With the milestone version 1.1.0 and now 1.2.0 the abstraction and division will now be revised. The implementation of plugins and new functions now requires a review of the existing code. This involves a lot of changes to code management and the package.
Why does it take so long for a version to come out?
There are currently several reasons for this:
- Replacing existing packages with new ones requires code conversion and a lot of testing.
- When replacing the binaries (e.g. new nginx version) I have to test that it is compiled with the extensions and functionality tests. (For example, there was an error in nginx_njs that I had to report as an ISSUE and then reproduce in collaboration with the developer).
- Changes to Docker and Containers, which again requires testing. (extensions and tests)
- Code refactoring, replacing code, switching to a new structure. Ironing out weird spots.
- I have started to write sub packages or other supports (because they are incomplete, no longer supported, errors have crept in)
- Bambooo - My frontend framework (for AdminLTE), which always gets updates.
- VTS - Data type validation library
- ETS - Error formatter fully written in Typescript.
- node-dns - Rewriting in Typescript, got no answer to my ISSUE
- node-forge-types - Correction of the *.d classes for certificate analysis and generation
- node-tuntap2 - TunTap API for VPN Service
- node-rohc - Scheduled for VPN Service
- rohc - Update (fix read write proc entry in kernel versions)
- many more ....
In progress
Docker Hub
I utilize the docker manifest for multi-platform awareness. Simply getting "stefanwerfling/flyingfish:latest" should get the correct image for your arch. However, you can also get specific Arch images via tags.
The architectures supported by this image are:
| Architecture | Available | Tag |
|---|---|---|
| x86-64 | ✅ | amd64-<version tag> |
| arm64 | ✅ | arm64v8-<version tag> |
Other platforms cannot be created as an image, because the restriction comes from the node docker image, but also because "certbot with pip" only supports amd64 and arm64 installation.
But it's better you run the installation with the instructions in Docker-Compose. Because FlyingFish consists of multiple images & containers.
Docker images (latest)
- stefanwerfling/flyingfish:latest
- stefanwerfling/flyingfish:v1.1.12
- stefanwerfling/flyingfish_ssh:latest
- stefanwerfling/flyingfish_ssh:v1.1.12
- stefanwerfling/flyingfish_himip:latest
- stefanwerfling/flyingfish_himip:v1.1.12
- stefanwerfling/flyingfish_ddns:latest
- stefanwerfling/flyingfish_ddns:v1.1.12
Screenshots
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Supported by
Special thanks to the following companys:
JetBrains |
Contributors
Special thanks to the following contributors:
Choppel |
License
This project is licensed under the GNU General Public License v3.0. See the LICENSE file for details.
