This is the bewCloud app built using Fresh and deployed using docker compose.
If you're looking for the desktop sync app, it's at bewcloud-desktop
.
If you're looking for the mobile app, it's at bewcloud-mobile
.
Or on your own machine, start with these commands:
mkdir data-files data-radicale radicale-config # local directories for storing user-uploaded files, radicale data, and radicale config (these last two are necessary only if you're using CalDav/CardDav/Contacts)
Now, download/copy the following configuration files (and tweak their contents as necessary, though no changes should yield a working — but very unsafe — setup):
docker-compose.yml
.env.sample
and save it as.env
bewcloud.config.sample.ts
and save it asbewcloud.config.ts
radicale-config/config
and save it asradicale-config/config
(necessary only if you're using CalDav/CardDav/Contacts)
Finally, run these commands:
docker compose up -d # makes the app available at http://localhost:8000
docker compose run --rm website bash -c "cd /app && make migrate-db" # initializes/updates the database (only needs to be executed the first time and on any data updates)
Note
If you run into permission issues, you can try running sudo chown -R 1993:1993 data-files
to fix them.
1993:1993
above comes from deno's docker image where 1993
is the default user id in it. It might change in the future since I don't control it.
If you're interested in building/contributing, check the Development section below.
Important
Even with signups disabled (config.auth.allowSignups=false
), the first signup will work and become an admin.
These are the amazing entities or individuals who are sponsoring this project for this current month. If you'd like to show up here, check the GitHub Sponsors page or make a donation above $50 ($100 to show up on the website)!
Important
Don't forget to set up your .env
file based on .env.sample
.
Don't forget to set up your bewcloud.config.ts
file based on bewcloud.config.sample.ts
.
- This was tested with
Deno
's version stated in the.dvmrc
file, though other versions may work. - For the postgres dependency (used when running locally or in CI), you should have
Docker
anddocker compose
installed.
docker compose -f docker-compose.dev.yml up # (optional) runs docker with postgres, locally
make migrate-db # runs any missing database migrations
make start # runs the app
make format # formats the code
make test # runs tests
make exec-db # runs psql inside the postgres container, useful for running direct development queries like `DROP DATABASE "bewcloud"; CREATE DATABASE "bewcloud";`
make build # generates all static files for production deploy
- Routes are defined at
routes/
. - Static files are defined at
static/
. - Frontend-only components are defined at
components/
. - Isomorphic components are defined at
islands/
. - Cron jobs are defined at
crons/
. - Reusable bits of code are defined at
lib/
. - Database migrations are defined at
db-migrations/
.
Just push to the main
branch.
CalDav/CardDav is now available since v2.3.0, using Radicale via Docker, which is already very efficient (and battle-tested). The "Contacts" client for CardDav is available since v2.4.0 and the "Calendar" client for CalDav is available since v2.5.0. Check this tag/release for custom-made server code where it was all mostly working, except for many edge cases, if you're interested.
In order to share a calendar, you can either have a shared user, or you can symlink the calendar to the user's own calendar (simply ln -s /<absolute-path-to-data-radicale>/collections/collection-root/<owner-user-id>/<calendar-to-share> /<absolute-path-to-data-radicale>/collections/collection-root/<user-id-to-share-with>/
).
Note
If you're running radicale with docker, the symlink needs to point to the container's directory, usually starting with /data
if you didn't change the radicale-config/config
, otherwise the container will fail to load the linked directory.
Public file sharing is now possible since v2.2.0. Check this PR for advanced sharing with internal and external users, with read and write access that was being done and almost working, if you're interested. I ditched all that complexity for simply using symlinks for internal sharing, as it served my use case (I have multiple data backups and trust the people I provide accounts to, with the symlinks).
You can simply ln -s /<absolute-path-to-data-files>/<owner-user-id>/<directory-to-share> /<absolute-path-to-data-files>/<user-id-to-share-with>/
to create a shared directory between two users, and the same directory can have different names, now.
Note
If you're running the app with docker, the symlink needs to point to the container's directory, usually starting with /app
if you didn't change the Dockerfile
, otherwise the container will fail to load the linked directory.
Check the website for screenshots or the YouTube channel for 1-minute demos.