- The DocuSign Open Source Alternative.
-
+ The Open Source DocuSign Alternative.
+ Learn more »
@@ -22,12 +20,16 @@
-
+
+> **🚧 We're currently working on a large scale refactor which can be found on the [feat/refresh](https://github.com/documenso/documenso/tree/feat/refresh) branch.**
+>
+> **[Read more on why 👀](https://documenso.com/blog/why-were-doing-a-rewrite)**
+
# Documenso 0.9 - Developer Preview
@@ -63,18 +65,28 @@ Signing documents digitally is fast, easy and should be best practice for every
## Community and Next Steps 🎯
-The current project goal is to [release a production ready version](https://github.com/documenso/documenso/milestone/1) for self-hosting as soon as possible. If you want to help making that happen you can:
+We're currently working on a redesign of the application including a revamp of the codebase so Documenso can be more intuitive to use and robust to develop upon.
- Check out the first source code release in this repository and test it
- Tell us what you think in the current [Discussions](https://github.com/documenso/documenso/discussions)
-- Join the [Slack Channel](https://documen.so/slack) for any questions and getting to know to other community members
+- Join the [Discord server](https://documen.so/discord) for any questions and getting to know to other community members
- ⭐ the repository to help us raise awareness
- Spread the word on Twitter, that Documenso is working towards a more open signing tool
- Fix or create [issues](https://github.com/documenso/documenso/issues), that are needed for the first production release
## Contributing
-- To contribute please see our [contribution guide](https://github.com/documenso/documenso/blob/main/CONTRIBUTING.md).
+- To contribute, please see our [contribution guide](https://github.com/documenso/documenso/blob/main/CONTRIBUTING.md).
+
+## Contact us
+
+Contact us if you are interested in our Enterprise plan for large organizations that need extra flexibility and control.
+
+
+
+## Activity
+
+
# Tech
@@ -89,10 +101,6 @@ Documenso is built using awesome open source tech including:
- [Node SignPDF (Digital Signature)](https://github.com/vbuch/node-signpdf)
- [React-PDF for viewing PDFs](https://github.com/wojtekmaj/react-pdf)
- [PDF-Lib for PDF manipulation](https://github.com/Hopding/pdf-lib)
-- [Zod for schema declaration and validation](https://zod.dev/)
-- [Lucide React for icons in React app](https://lucide.dev/)
-- [Framer Motion for motion library](https://www.framer.com/motion/)
-- [Radix UI for component library](https://www.radix-ui.com/)
- Check out `/package.json` and `/apps/web/package.json` for more
- Support for [opensignpdf (requires Java on server)](https://github.com/open-pdf-sign) is currently planned.
@@ -135,37 +143,47 @@ Your database will also be available on port `54320`. You can connect to it usin
## Developer Setup
+### Manual Setup
+
Follow these steps to setup documenso on you local machine:
- [Clone the repository](https://help.github.com/articles/cloning-a-repository/) it to your local device.
```sh
git clone https://github.com/documenso/documenso
```
-- Run npm i in root directory
-- Rename .env.example to .env
+- Run `npm i` in root directory
+- Rename `.env.example` to `.env`
- Set DATABASE_URL value in .env file
- You can use the provided test database url (may be wiped at any point)
- Or setup a local postgres sql instance (recommended)
-- Create the database scheme by running db-migrate:dev
+- Create the database scheme by running `db-migrate:dev`
- Setup your mail provider
- - Set SENDGRID_API_KEY value in .env file
+ - Set `SENDGRID_API_KEY` value in .env file
- You need a SendGrid account, which you can create [here](https://signup.sendgrid.com/).
- - Documenso uses [Nodemailer](https://nodemailer.com/about/) so you can easily use your own SMTP server by setting the SMTP\_\* variables in your .env
-- Run npm run dev root directory to start
+ - Documenso uses [Nodemailer](https://nodemailer.com/about/) so you can easily use your own SMTP server by setting the `SMTP
+ \_
+ * variables` in your .env
+- Run `npm run dev` root directory to start
- Register a new user at http://localhost:3000/signup
---
-- Optional: Seed the database using npm run db-seed to create a test user and document
-- Optional: Upload and sign apps/web/resources/example.pdf manually to test your setup
+- Optional: Seed the database using `npm run db-seed` to create a test user and document
+- Optional: Upload and sign `apps/web/resources/example.pdf` manually to test your setup
- Optional: Create your own signing certificate
- A demo certificate is provided in `/app/web/resources/certificate.p12`
- To generate your own using these steps and a Linux Terminal or Windows Subsystem for Linux (WSL) see **[Create your own signing certificate](#creating-your-own-signing-certificate)**.
+### Run in Gitpod
+
+- Click below to launch a ready-to-use Gitpod workspace in your browser.
+
+[](https://gitpod.io/#https://github.com/documenso/documenso)
+
## Updating
-- If you pull the newest version from main, using git pull, it may be necessary to regenerate your database client
+- If you pull the newest version from main, using `git pull`, it may be necessary to regenerate your database client
- You can do this by running the generate command in `/packages/prisma`:
```sh
npx prisma generate
@@ -176,16 +194,22 @@ Follow these steps to setup documenso on you local machine:
For the digital signature of your documents you need a signing certificate in .p12 format (public and private key). You can buy one (not recommended for dev) or use the steps to create a self-signed one:
-1. Generate a private key using the OpenSSL command. You can run the following command to generate a 2048-bit RSA key:\
- openssl genrsa -out private.key 2048
+1. Generate a private key using the OpenSSL command. You can run the following command to generate a 2048-bit RSA key:
+
+ `openssl genrsa -out private.key 2048`
+
+2. Generate a self-signed certificate using the private key. You can run the following command to generate a self-signed certificate:
+
+ `openssl req -new -x509 -key private.key -out certificate.crt -days 365`
-2. Generate a self-signed certificate using the private key. You can run the following command to generate a self-signed certificate:\
- openssl req -new -x509 -key private.key -out certificate.crt -days 365 \
This will prompt you to enter some information, such as the Common Name (CN) for the certificate. Make sure you enter the correct information. The -days parameter sets the number of days for which the certificate is valid.
-3. Combine the private key and the self-signed certificate to create the p12 certificate. You can run the following command to do this: \
- openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt
+
+3. Combine the private key and the self-signed certificate to create the p12 certificate. You can run the following command to do this:
+
+ `openssl pkcs12 -export -out certificate.p12 -inkey private.key -in certificate.crt`
+
4. You will be prompted to enter a password for the p12 file. Choose a strong password and remember it, as you will need it to use the certificate (**can be empty for dev certificates**)
-5. Place the certificate /apps/web/resources/certificate.p12
+5. Place the certificate `/apps/web/resources/certificate.p12`
# Docker
@@ -193,16 +217,42 @@ For the digital signature of your documents you need a signing certificate in .p
Want to create a production ready docker image? Follow these steps:
-- Run `./docker/build.sh` in the root directory.
-- Publish the image to your docker registry of choice.
+- cd into `docker` directory
+- Make `build.sh` executable by running `chmod +x build.sh`
+- Run `./build.sh` to start building the docker image.
+- Publish the image to your docker registry of choice (or) If you prefer running the image from local, run the below command
-# Deploying - Coming Soon™
+```
+docker run -d --restart=unless-stopped -p 3000:3000 -v documenso:/app/data --name documenso documenso:latest
+```
-- Docker support
-- One-Click-Deploy on Render.com Deploy
+Command Breakdown:
+- `-d` - Let's you run the container in background
+- `-p` - Passes down which ports to use. First half is the host port, Second half is the app port. You can change the first half anything you want and reverse proxy to that port.
+- `-v` - Volume let's you persist the data
+- `--name` - Name of the container
+- `documenso:latest` - Image you have built
+
+# Deployment
+
+We support a variety of deployment methods, and are actively working on adding more. Stay tuned for updates!
+
+## Railway
+
+[](https://railway.app/template/DjrRRX)
+
+## Render
+
+[](https://render.com/deploy?repo=https://github.com/documenso/documenso)
# Troubleshooting
+## I'm not receiving any emails when using the developer quickstart
+
+When using the developer quickstart an [Inbucket](https://inbucket.org/) server will be spun up in a docker container that will store all outgoing email locally for you to view.
+
+The Web UI can be found at http://localhost:9000 while the SMTP port will be on localhost:2500.
+
## Support IPv6
In case you are deploying to a cluster that uses only IPv6. You can use a custom command to pass a parameter to the NextJS start command
diff --git a/apps/marketing/content/blog/building-documenso-pt1.mdx b/apps/marketing/content/blog/building-documenso-pt1.mdx
index 92c6f61ed..b8507be03 100644
--- a/apps/marketing/content/blog/building-documenso-pt1.mdx
+++ b/apps/marketing/content/blog/building-documenso-pt1.mdx
@@ -1,98 +1,98 @@
----
-title: 'Building Documenso — Part 1: Certificates'
-description: In today's fast-paced world, productivity and efficiency are crucial for success, both in personal and professional endeavors. We all strive to make the most of our time and energy to achieve our goals effectively. However, it's not always easy to stay on track and maintain peak performance. In this blog post, we'll explore 10 valuable tips to help you boost productivity and efficiency in your daily life.
-authorName: 'Timur Ercan'
-authorImage: '/blog/blog-author-timur.jpeg'
-authorRole: 'Co-Founder'
-date: 2023-06-23
-tags:
- - Open Source
- - Document Signature
- - Certificates
- - Signing
----
-
-
-
-
-
- What actually is a signature?
-
-
-
-> Disclaimer: I’m not a lawyer and this isn’t legal advice. We plan to publish a much more specific framework on the topic of signature validity.
-
-This is the first installment of the new Building Documenso series, where I describe the challenges and design choices that we make while building the world’s most open signing platform.
-
-As you may have heard, we launched the community-reviewed version 0.9 of Documenso on GitHub recently and it’s now available through the early adopter’s plan. One of the most fundamental choices we had to make on this first release, was the choice of certificate. While it’s interesting to know what we opted for, this shall also serve as a guide for everyone facing the same choice for self-hosting Documenso.
-
-> Question: Why do I need a document signing certificate to self-host?
->
-> Short Answer: Inserting the images of a signature into the document is only part of the signing process.
-
-To have an actual digitally signed document you need a document signing certificate that is used to create the digital signature that is inserted into the document, alongside the visible one¹.
-
-When hosting a signature service yourself, as we do, there are four main choices for handling the certificate: Not using a certificate, creating your own, buying a trusted certificate, and becoming and trusted service provider to issue your own trusted certificate.
-
-## 1\. No Certificate
-
-A lot of signing services actually don’t employ actual digital signatures besides the inserted image. The only insert and image of the signatures into the document you sign. This can be done and is legally acceptable in many cases. This option isn’t directly supported by Documenso without changing the code.
-
-## 2\. Create your own
-
-Since the cryptography behind certificates is freely available as open source you could generate your own using OpenSSL for example. Since it’s hardly more work than option 1 (using Documenso at least), this would be my minimum effort recommendation. Having a self-created (“self-signed”) certificate doesn’t add much in terms of regulation but it guarantees the document’s integrity, meaning no changes have been made after signing². What this doesn’t give you, is the famous green checkmark in Adobe Acrobat. Why? Because you aren’t on the list of providers Adobe “trusts”.³
-
-## 3\. Buy a “trusted” certificate.
-
-There are Certificate Authorities (CAs) that can sell you a certificate⁴. The service they provide is, that they validate your name (personal certificates) or your organization’s name (corporate certificate) before creating your certificate for you, just like you did in option 2. The difference is, that they are listed on the previously mentioned trust lists (e.g. Adobe’s) and thus the resulting signatures get a nice, green checkmark in Adobe Reader⁵
-
-## 4\. Becoming a Trusted Certificate Authority (CA) yourself and create your own certificate
-
-This option is an incredibly complex endeavour, requiring a lot of effort and skill. It can be done, as there are multiple CAs around the world. Is it worth the effort? That depends a lot on what you’re trying to accomplish.
-
-
. . .
-
-## What we did
-
-Having briefly introduced the options, here is what we did: Since we aim to raise the bar on digital signature proliferation and trust, we opted to buy an “Advanced Personal Certificates for Companies/Organisations” from WiseKey. Thus, documents signed with Documenso’s hosted version look like this:
-
-
-
-
- The famous green checkmark: Signed by hosted Documenso
-
-
-There weren’t any deeper reasons we choose WiseKey, other than they offered what we needed and there wasn’t any reason to look much further. While I didn’t map the entire certificate market offering (yet), I’m pretty sure something similar could be found elsewhere. While we opted for option 3, choosing option 2 might be perfectly reasonable considering your use case.⁶
-
-> While this is our setup, for now, we have a bigger plan for this topic. While globally trusted SSL Certificates have been available for free, courtesy of Let’s Encrypt, for a while now, there is no such thing as document signing. And there should be. Not having free and trusted infrastructure for signing is blocking a completely new generation of signing products from being created. This is why we’ll start working on option 4 when the time is right.
-
-Do you have questions or thoughts about this? As always, let me know in the comments, on twitter.com/eltimuro
-or directly: documen.so/timur
-
-Join the self-hoster community here: https://documenso.slack.com/
-
-Best from Hamburg
-
-Timur
-
-\[1\] There are different approaches to signing a document. For the sake of simplicity, here we talk about a document with X inserted signature images, that is afterward signed once the by signing service, i.e. Documenso. If each visual signature should have its own digital one (e.g. QES — eIDAS Level 3), the case is a bit more complex.
-
-\[2\] Of course, the signing service provider technically can change and resign the document, especially in the case mentioned in \[1\]. This can be countered by requiring actual digital signatures from each signer, that are bound to their identity/ account. Creating a completely trustless system in the context however is extremely hard to do and not the most pressing business need for the industry at this point, in my opinion. Though, this would be nice.
-
-\[3\] Adobe, like the EU, has a list of organizations they trust. The Adobe green checkmark is powered by the Adobe trust list, if you want to be trusted by EU standards here: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation, you need to be on the EU trust list. Getting on each list is possible, though the latter is much more work.
-
-\[4\] Technically, they sign your certificate creation request (created by you), containing your info with their certificate (which is trusted), making your certificate trusted. This way, everything you sign with your certificate is seen as trusted. They created their certificate just like you, the difference is they are on the lists, mentioned in \[3\]
-
-\[5\] Why does Adobe get to say, what is trusted? They simply happen to have the most used pdf viewer. And since everyone checks there, whom they consider trusted carries weight. If it should be like this, is a different matter.
-
-\[6\] Self-Signed signatures, even purely visual signatures, are fully legally binding. Why you use changes mainly your confidence in the signature and the burden of proof. Also, some industries require a certain level of signatures e.g. retail loans (QES/ eIDAS Level 3 in the EU).
+---
+title: 'Building Documenso — Part 1: Certificates'
+description: This is the first part of the new Building Documenso series, where I describe the challenges and design choices that we make while building the world’s most open signing platform.
+authorName: 'Timur Ercan'
+authorImage: '/blog/blog-author-timur.jpeg'
+authorRole: 'Co-Founder'
+date: 2023-06-23
+tags:
+ - Open Source
+ - Document Signature
+ - Certificates
+ - Signing
+---
+
+
+
+
+
+ What actually is a signature?
+
+
+
+> Disclaimer: I’m not a lawyer and this isn’t legal advice. We plan to publish a much more specific framework on the topic of signature validity.
+
+This is the first installment of the new Building Documenso series, where I describe the challenges and design choices that we make while building the world’s most open signing platform.
+
+As you may have heard, we launched the community-reviewed version 0.9 of Documenso on GitHub recently and it’s now available through the early adopter’s plan. One of the most fundamental choices we had to make on this first release, was the choice of certificate. While it’s interesting to know what we opted for, this shall also serve as a guide for everyone facing the same choice for self-hosting Documenso.
+
+> Question: Why do I need a document signing certificate to self-host?
+>
+> Short Answer: Inserting the images of a signature into the document is only part of the signing process.
+
+To have an actual digitally signed document you need a document signing certificate that is used to create the digital signature that is inserted into the document, alongside the visible one¹.
+
+When hosting a signature service yourself, as we do, there are four main choices for handling the certificate: Not using a certificate, creating your own, buying a trusted certificate, and becoming and trusted service provider to issue your own trusted certificate.
+
+## 1\. No Certificate
+
+A lot of signing services actually don’t employ actual digital signatures besides the inserted image. The only insert and image of the signatures into the document you sign. This can be done and is legally acceptable in many cases. This option isn’t directly supported by Documenso without changing the code.
+
+## 2\. Create your own
+
+Since the cryptography behind certificates is freely available as open source you could generate your own using OpenSSL for example. Since it’s hardly more work than option 1 (using Documenso at least), this would be my minimum effort recommendation. Having a self-created (“self-signed”) certificate doesn’t add much in terms of regulation but it guarantees the document’s integrity, meaning no changes have been made after signing². What this doesn’t give you, is the famous green checkmark in Adobe Acrobat. Why? Because you aren’t on the list of providers Adobe “trusts”.³
+
+## 3\. Buy a “trusted” certificate.
+
+There are Certificate Authorities (CAs) that can sell you a certificate⁴. The service they provide is, that they validate your name (personal certificates) or your organization’s name (corporate certificate) before creating your certificate for you, just like you did in option 2. The difference is, that they are listed on the previously mentioned trust lists (e.g. Adobe’s) and thus the resulting signatures get a nice, green checkmark in Adobe Reader⁵
+
+## 4\. Becoming a Trusted Certificate Authority (CA) yourself and create your own certificate
+
+This option is an incredibly complex endeavour, requiring a lot of effort and skill. It can be done, as there are multiple CAs around the world. Is it worth the effort? That depends a lot on what you’re trying to accomplish.
+
+
. . .
+
+## What we did
+
+Having briefly introduced the options, here is what we did: Since we aim to raise the bar on digital signature proliferation and trust, we opted to buy an “Advanced Personal Certificates for Companies/Organisations” from WiseKey. Thus, documents signed with Documenso’s hosted version look like this:
+
+
+
+
+ The famous green checkmark: Signed by hosted Documenso
+
+
+There weren’t any deeper reasons we choose WiseKey, other than they offered what we needed and there wasn’t any reason to look much further. While I didn’t map the entire certificate market offering (yet), I’m pretty sure something similar could be found elsewhere. While we opted for option 3, choosing option 2 might be perfectly reasonable considering your use case.⁶
+
+> While this is our setup, for now, we have a bigger plan for this topic. While globally trusted SSL Certificates have been available for free, courtesy of Let’s Encrypt, for a while now, there is no such thing as document signing. And there should be. Not having free and trusted infrastructure for signing is blocking a completely new generation of signing products from being created. This is why we’ll start working on option 4 when the time is right.
+
+Do you have questions or thoughts about this? As always, let me know in the comments, on twitter.com/eltimuro
+or directly: documen.so/timur
+
+Join the self-hoster community here: https://documen.so/discord
+
+Best from Hamburg
+
+Timur
+
+\[1\] There are different approaches to signing a document. For the sake of simplicity, here we talk about a document with X inserted signature images, that is afterward signed once the by signing service, i.e. Documenso. If each visual signature should have its own digital one (e.g. QES — eIDAS Level 3), the case is a bit more complex.
+
+\[2\] Of course, the signing service provider technically can change and resign the document, especially in the case mentioned in \[1\]. This can be countered by requiring actual digital signatures from each signer, that are bound to their identity/ account. Creating a completely trustless system in the context however is extremely hard to do and not the most pressing business need for the industry at this point, in my opinion. Though, this would be nice.
+
+\[3\] Adobe, like the EU, has a list of organizations they trust. The Adobe green checkmark is powered by the Adobe trust list, if you want to be trusted by EU standards here: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation, you need to be on the EU trust list. Getting on each list is possible, though the latter is much more work.
+
+\[4\] Technically, they sign your certificate creation request (created by you), containing your info with their certificate (which is trusted), making your certificate trusted. This way, everything you sign with your certificate is seen as trusted. They created their certificate just like you, the difference is they are on the lists, mentioned in \[3\]
+
+\[5\] Why does Adobe get to say, what is trusted? They simply happen to have the most used pdf viewer. And since everyone checks there, whom they consider trusted carries weight. If it should be like this, is a different matter.
+
+\[6\] Self-Signed signatures, even purely visual signatures, are fully legally binding. Why you use changes mainly your confidence in the signature and the burden of proof. Also, some industries require a certain level of signatures e.g. retail loans (QES/ eIDAS Level 3 in the EU).
diff --git a/apps/marketing/content/blog/deploy-with-vercel-supabase-resend.mdx b/apps/marketing/content/blog/deploy-with-vercel-supabase-resend.mdx
new file mode 100644
index 000000000..fb00f40bf
--- /dev/null
+++ b/apps/marketing/content/blog/deploy-with-vercel-supabase-resend.mdx
@@ -0,0 +1,198 @@
+---
+title: 'Deploying Documenso with Vercel, Supabase and Resend'
+description: This is the first part of the new Building Documenso series, where I describe the challenges and design choices that we make while building the world’s most open signing platform.
+authorName: 'Ephraim Atta-Duncan'
+authorImage: '/blog/blog-author-duncan.jpeg'
+authorRole: 'Software Engineer Intern'
+date: 2023-09-08
+tags:
+ - Open Source
+ - Self Hosting
+ - Tutorial
+---
+
+In this article, we'll walk you through how to deploy and self-host Documenso using Vercel, Supabase, and Resend.
+
+You'll learn:
+
+- How to set up a Postgres database using Supabase,
+- How to install SMTP with Resend,
+- How to deploy your project with Vercel.
+
+If you don't know what [Documenso](https://documenso.com/) is, it's an open-source alternative to DocuSign, with the mission to create an open signing infrastructure while embracing openness, cooperation, and transparency.
+
+## Prerequisites
+
+Before we start, make sure you have a [GitHub](https://github.com/signup) account. You also need [Node.js](https://nodejs.org/en) and [npm](https://www.npmjs.com/) installed on your local machine (note: you also have the option to host it on a cloud environment using Gitpod for example; that would be another post). If you need accounts on Vercel, Supabase, and Resend, create them by visiting the [Vercel](https://vercel.com/), [Supabase](https://supabase.com/), and [Resend](https://resend.com/) websites.
+
+Checklist:
+
+- [ ] Have a GitHub account
+- [ ] Install Node.js
+- [ ] Install npm
+- [ ] Have a Vercel account
+- [ ] Have a Supabase account
+- [ ] Have a Resend account
+
+## Step-by-Step guide to deploying Documenso with Vercel, Supabase, and Resend
+
+To deploy Documenso, we'll take the following steps:
+
+1. Fork the Documenso repository
+2. Clone the forked repository and install dependencies
+3. Create a new project on Supabase
+4. Copy the Supabase Postgres database connection URL
+5. Create a `.env` file
+6. Run the migration on the Supabase Postgres Database
+7. Get your SMTP Keys on Resend
+8. Create a new project on Vercel
+9. Add Environment Variables to your Vercel project
+
+So, you're ready? Let’s dive in!
+
+### Step 1: Fork the Documenso repository
+
+Start by creating a fork of Documenso on GitHub. You can do this by visiting the [Documenso repository](https://github.com/documenso/documenso) and clicking on the 'Fork' button. (Also, star the repo!)
+
+
+
+Choose your GitHub profile as the owner and click on 'Create fork' to create a fork of the repo.
+
+
+
+### Step 2: Clone the forked repository and install dependencies
+
+Clone the forked repository to your local machine in any directory of your choice. Open your terminal and enter the following commands:
+
+```bash
+# Clone the repo using Github CLI
+gh repo clone [your_github_username]/documenso
+
+# Clone the repo using Git
+git clone
+```
+
+You can now navigate into the directory and install the project’s dependencies:
+
+```bash
+cd documenso
+npm install
+```
+
+### Step 3: Create a new project on Supabase
+
+Now, let's set up the database.
+
+If you haven't already, create a new project on Supabase. This will automatically create a new Postgres database for you.
+
+On your Supabase dashboard, click the '**New project**' button and choose your organization.
+
+On the '**Create a new project**' page, set a database name of **documenso** and a secure password for your database. Choose a region closer to you, a pricing plan, and click on '**Create new project**' to create your project.
+
+
+
+### Step 4: Copy the Supabase Postgres database connection URL
+
+In your project, click the '**Settings**' icon at the bottom left.
+
+Under the '**Project Settings**' section, click '**Database**' and scroll down to the '**Connection string**' section. Copy the '**URI**' and update it with the password you chose in the previous step.
+
+
+
+### Step 5: Create a `.env` file
+
+Create a `.env` file in the root of your project by copying the contents of the `.env.example` file.
+
+Add the connection string you copied from your Supabase dashboard to the `DATABASE_URL` variable in the `.env` file.
+
+The `.env` should look like this:
+
+```bash
+DATABASE_URL="postgres://postgres:[YOUR-PASSWORD]@db.[YOUR-PROJECT-REF].supabase.co:5432/postgres"
+```
+
+### Step 6: Run the migration on the Supabase Postgres Database
+
+Run the migration on the Supabase Postgres Database using the following command:
+
+```bash
+npx prisma migrate deploy
+```
+
+### Step 7: Get your SMTP Keys on Resend
+
+So, you've just cloned Documenso, installed dependencies on your local machine, and set your database using Supabase. Now, SMTP is missing. Emails won't go out! Let's fix it with Resend.
+
+In the **[Resend](https://resend.com/)** dashboard, click 'Add API Key' to create a key for Resend SMTP.
+
+
+
+Next, add and verify your domain in the '**Domains**' section on the sidebar. This will allow you to send emails from any address associated with your domain.
+
+
+
+You can update your `.env` file with the following:
+
+```jsx
+SMTP_MAIL_HOST = 'smtp.resend.com';
+SMTP_MAIL_PORT = '25';
+SMTP_MAIL_USER = 'resend';
+SMTP_MAIL_PASSWORD = 'YOUR_RESEND_API_KEY';
+MAIL_FROM = 'noreply@[YOUR_DOMAIN]';
+```
+
+### Step 8: Create a new project on Vercel
+
+You set the database with Supabase and are SMTP-ready with Resend. Almost there! The next step is to deploy the project — we'll use Vercel for that.
+
+On your Vercel dashboard, create a new project using the forked project from your GitHub repositories. Select the project among the options and click '**Import**' to start running Documenso.
+
+
+
+### Step 9: Add Environment Variables to your Vercel project
+
+In the '**Configure Project**' page, adding the required Environmental Variables is essential to ensure the application deploys without any errors.
+
+Specifically, for the `NEXT_PUBLIC_WEBAPP_URL` and `NEXTAUTH_URL` variables, you must add `.vercel.app` to your Project Name. This will form the deployment URL, which will be in the format: `https://[project_name].vercel.app`.
+
+For example, in my case, the deployment URL is `https://documenso-supabase-web.vercel.app`.
+
+
+
+This is a sample `.env` to deploy. Copy and paste it to auto-populate the fields and click ‘**Deploy.’** Now, you only need to wait for your project to deploy. You’re going live — enjoy!
+
+```bash
+DATABASE_URL='postgresql://postgres:typeinastrongpassword@db.njuigobjlbteahssqbtw.supabase.co:5432/postgres'
+
+NEXT_PUBLIC_WEBAPP_URL='https://documenso-supabase-web.vercel.app'
+NEXTAUTH_SECRET='something gibrish to encrypt your jwt tokens'
+NEXTAUTH_URL='https://documenso-supabase-web.vercel.app'
+
+# Get a Sendgrid Api key here:
+SENDGRID_API_KEY=''
+
+# Set SMTP credentials to use SMTP instead of the Sendgrid API.
+SMTP_MAIL_HOST='smtp.resend.com'
+SMTP_MAIL_PORT='25'
+SMTP_MAIL_USER='resend'
+SMTP_MAIL_PASSWORD='YOUR_RESEND_API_KEY'
+MAIL_FROM='noreply@[YOUR_DOMAIN]'
+
+NEXT_PUBLIC_ALLOW_SIGNUP=true
+```
+
+## Wrapping up
+
+
+
+Congratulations! 🎉 You've successfully deployed Documenso using Vercel, Supabase, and Resend. You're now ready to create and sign your own documents with your self-hosted Documenso!
+
+In this step-by-step guide, you learned how to:
+
+- set up a Postgres database using Supabase,
+- install SMTP with Resend,
+- deploy your project with Vercel.
+
+Over to you! How was the tutorial? If you enjoyed it, [please do share](https://twitter.com/documenso/status/1700141802693480482)! And if you have any questions or comments, please reach out to me on [Twitter / X](https://twitter.com/EphraimDuncan_) (DM open) or [Discord](https://documen.so/discord).
+
+We're building an open-source alternative to DocuSign and welcome every contribution. Head over to the GitHub repository and [leave us a Star](https://github.com/documenso/documenso)!
diff --git a/apps/marketing/content/blog/next.mdx b/apps/marketing/content/blog/next.mdx
index 4f846a0a7..c241cf3eb 100644
--- a/apps/marketing/content/blog/next.mdx
+++ b/apps/marketing/content/blog/next.mdx
@@ -12,7 +12,7 @@ tags:
Since we launched [Documenso 0.9 on Product Hunt](https://producthunt.com/products/documenso#documenso) last May, the team's been hard at work behind the scenes to ramp up development and design to deliver an excellent next version.
-Last week, Lucas shared the reasoning how [why we're doing a rewrite](https://documenso.com/blog/why-were-doing-a-rewrite).
+Last week, Lucas shared the reasoning on [why we're doing a rewrite](https://documenso.com/blog/why-were-doing-a-rewrite).
Today, I'm pleased to share with you a preview of the next Documenso.
diff --git a/apps/marketing/content/blog/why-were-doing-a-rewrite.mdx b/apps/marketing/content/blog/why-were-doing-a-rewrite.mdx
new file mode 100644
index 000000000..f2195a019
--- /dev/null
+++ b/apps/marketing/content/blog/why-were-doing-a-rewrite.mdx
@@ -0,0 +1,113 @@
+---
+title: Why we're doing a rewrite
+description: As we move beyond MVP and onto creating the open signing infrastructure we all deserve we need to take a quick pit-stop.
+authorName: 'Lucas Smith'
+authorImage: '/blog/blog-author-lucas.png'
+authorRole: 'Co-Founder'
+date: 2023-08-05
+tags:
+ - Community
+ - Development
+---
+
+
+
+
+
+ The next generation of Documenso and signing infrastructure.
+
+
+
+> TLDR; We're rewriting Documenso to move on from our MVP foundations and create an even better base for the project. This rewrite will provide us the opportunity to fix a few things within the project while enabling a faster development process moving forward.
+
+# Introduction
+
+At Documenso, we're building the next generation of signing infrastructure with a focus on making it inclusive and accessible for all. To do this we need to ensure that the software we write is also inclusive and accessible and for this reason we’ve decided to take a step back and perform a _quick_ rewrite.
+
+Although we've achieved validated MVP status and gained paying customers, we're still quite far from our goal of creating a trusted, open signing experience. To move closer to that future, we need to step back and focus on the project's foundations to ensure we can solve all the items we set out to on our current homepage.
+
+Fortunately, this wasn't a case of someone joining the team and proposing a rewrite due to a lack of understanding of the codebase and context surrounding it. Prior to joining Documenso as a co-founder, I had spent an extensive amount of time within the Documenso codebase and had a fairly intimate understanding of what was happening for the most part. This knowledge allowed me to make the fair and simultaneously hard call to take a quick pause so we can rebuild our current foundations to enable accessibility and a faster delivery time in the future.
+
+# The Reasoning: TypeScript
+
+Our primary reason for the rewrite is to better leverage the tools and technologies we've already chosen, namely TypeScript. While Documenso currently uses TypeScript, it's not fully taking advantage of its safety features, such as generics and type guards.
+
+The codebase currently has several instances of `any` types, which is expected when working in an unknown domain where object models aren't fully understood before exploration and experimentation. These `any`s initially sped up development, but have since become a hindrance due to the lack of type information, combined with prop drilling. As a result, it's necessary to go through a lot of context to understand the root of any given issue.
+
+The rewrite is using TypeScript to its full potential, ensuring that every interaction is strongly typed, both through general TypeScript tooling and the introduction of [Zod](https://github.com/colinhacks/zod), a validation library with excellent TypeScript support. With these choices, we can ensure that the codebase is robust to various inputs and states, as most issues will be caught during compile time and flagged within a developer's IDE.
+
+# The Reasoning: Stronger API contracts
+
+In line with our pattern of creating strongly typed contracts, we've decided to use [tRPC](https://github.com/trpc/trpc) for our internal API. This enables us to share types between our frontend and backend and establish a solid contract for interactions between the two. This is in contrast to the currently untyped API endpoints in Documenso, which are accessed using the `fetch` API that is itself untyped.
+
+Using tRPC drastically reduces the chance of failures resulting from mundane things like argument or response shape changes during updates and upgrades. We made this decision easily because tRPC is a mature technology with no signs of losing momentum any time soon.
+
+Additionally, many of our open-source friends have made the same choice for similar reasons.
+
+# The Reasoning: Choosing exciting technologies
+
+Although we already work with what I consider to be a fun stack that includes Next.js, Prisma, Tailwind, and more, it's no secret that contributors enjoy working with new technologies that benefit them in their own careers and projects.
+
+To take advantage of this, we have decided to use Next.js 13 and React's new server component and actions architecture. Server components are currently popular among developers, with many loving and hating them at the same time.
+
+I have personally worked with server components and actions since they were first released in October 2022 and have dealt with most of the hiccups and limitations along the way. Now, in July 2023, I believe they are in a much more stable place and are ready to be adopted, with their benefits being recognised by many.
+
+By choosing to use server components and actions, we hope to encourage the community to participate more than they otherwise might. However, we are only choosing this because it has become more mature and stable. We will not choose things that are less likely to become the de-facto solution in the future, as we do not wish to inherit a pile of tech debt later on.
+
+# The Reasoning: Allowing concurrent work
+
+Another compelling reason for the rewrite was to effectively modularise code so we can work on features concurrently and without issue. This means extracting as much as possible out of components, API handlers and more and into a set of methods and functions that attempt to focus on just one thing.
+
+In performing this work we should be able to easily make refactors and other changes to various parts of the code without stepping on each others feet, this also grants us the ability to upgrade or deprecate items as required by sticking to the contract of the previous method.
+
+Additionally, this makes testing a much easier task as we can focus more on units of work rather than extensive end to end testing although we aim to have both, just not straight away.
+
+# The Reasoning: Licensing of work
+
+Another major reasoning for the rewrite is to ensure that all work performed on the project by both our internal team and external contributors is licensed in a way that benefits the project long-term. Prior to the rewrite contributors would create pull requests that would be merged in without any further process outside of the common code-review and testing cycles.
+
+This was fine for the most part since we were simply working on the MVP but now as we move towards an infrastructure focus we intend on taking on enterprise clients who will have a need for a non-GPLv3 license since interpretations of it can be quite harmful to private hosting, to facilitate this we will require contributors to sign a contributor license agreement (CLA) prior to their changes being merged which will assign a perpetual license for us to use their code and relicense it as required such as for the use-case above.
+
+While some might cringe at the idea of signing a CLA, we want to offer a compelling enterprise offering through means of dual-licensing. Great enterprise adoption is one of the cornerstones of our strategy and will be key to funding community and product development long-term.
+
+_Do note that the above does not mean that we will ever go closed-source, it’s a point in our investor agreements that [https://github.com/documenso/documenso](https://github.com/documenso/documenso) will always remain available and open-source._
+
+# Goals and Non-Goals
+
+Rewriting an application is a monumental task that I have taken on and rejected many times in my career. As I get older, I become more hesitant to perform these rewrites because I understand that systems carry a lot of context and history. This makes them better suited for piecemeal refactoring instead, which avoids learning the lessons of the past all over again during the launch of the rewrite.
+
+To ensure that we aren't just jumping off the deep end, I have set out a list of goals and non-goals to keep this rewrite lean and affordable.
+
+### Goals
+
+- Provide a clean design and interface for the newly rewritten application that creates a sense of trust and security at first glance.
+- Create a stable foundation and architecture that will allow for growth into our future roadmap items (teams, automation, workflows, etc.).
+- Create a robust system that requires minimal context through strong contracts and typing.
+
+### Non-Goals
+
+- Change the database schema (we don't want to make migration harder than it needs to be, thus all changes must be additive).
+- Add too many features that weren't in the system prior to the rewrite.
+- Remove any features that were in the older version of Documenso, such as free signatures (signatures that have no corresponding field).
+
+# Rollout Plan
+
+Thanks to the constraints listed above our rollout will hopefully be fairly painless, still to be safe we plan on doing the following.
+
+1. In the current [testing environment](https://test.documenso.com), create and sign a number of documents leaving many in varying states of completion.
+2. Deploy the rewrite to the testing environment and verify that all existing documents and information is retrievable and modifiable without any issue.
+3. Create another set of documents using the new rewrite and verify that all interactions between authoring and signing work as expected.
+4. Repeat this until we reach a general confidence level (expectation of two weeks).
+
+Once we’ve reached the desired confidence level with our testing environment we will look to deploy the rewrite to the production environment ensuring that we’ve performed all the required backups in the event of a catastrophic failure.
+
+# Want to help out?
+
+We’re currently working on the **[feat/refresh](https://github.com/documenso/documenso/tree/feat/refresh)** branch on GitHub, we aim to have a CLA available to sign in the coming days so we can start accepting external contributions asap. While we’re nearing the end-stage of the rewrite we will be throwing up a couple of bounties shortly for things like [Husky](https://github.com/typicode/husky) and [Changesets](https://github.com/changesets/changesets).
+
+Keep an eye on our [GitHub issues](https://github.com/documenso/documenso/issues) to stay up to date!
diff --git a/apps/marketing/next.config.js b/apps/marketing/next.config.js
index ee7d10899..2783e4063 100644
--- a/apps/marketing/next.config.js
+++ b/apps/marketing/next.config.js
@@ -8,9 +8,50 @@ const { parsed: env } = require('dotenv').config({
/** @type {import('next').NextConfig} */
const config = {
+ experimental: {
+ serverActions: true,
+ },
reactStrictMode: true,
transpilePackages: ['@documenso/lib', '@documenso/prisma', '@documenso/trpc', '@documenso/ui'],
- env,
+ modularizeImports: {
+ 'lucide-react': {
+ transform: 'lucide-react/dist/esm/icons/{{ kebabCase member }}',
+ },
+ },
+ async headers() {
+ return [
+ {
+ source: '/:path*',
+ headers: [
+ {
+ key: 'x-dns-prefetch-control',
+ value: 'on',
+ },
+ {
+ key: 'strict-transport-security',
+ value: 'max-age=31536000; includeSubDomains; preload',
+ },
+ {
+ key: 'x-frame-options',
+ value: 'SAMEORIGIN',
+ },
+ {
+ key: 'x-content-type-options',
+ value: 'nosniff',
+ },
+ {
+ key: 'referrer-policy',
+ value: 'strict-origin-when-cross-origin',
+ },
+ {
+ key: 'permissions-policy',
+ value:
+ 'accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()',
+ },
+ ],
+ },
+ ];
+ },
};
module.exports = withContentlayer(config);
diff --git a/apps/marketing/process-env.d.ts b/apps/marketing/process-env.d.ts
index ac170a616..3dfdcb30f 100644
--- a/apps/marketing/process-env.d.ts
+++ b/apps/marketing/process-env.d.ts
@@ -1,6 +1,7 @@
declare namespace NodeJS {
export interface ProcessEnv {
- NEXT_PUBLIC_SITE_URL?: string;
+ NEXT_PUBLIC_WEBAPP_URL?: string;
+ NEXT_PUBLIC_MARKETING_URL?: string;
NEXT_PRIVATE_DATABASE_URL: string;
diff --git a/apps/marketing/public/blog/blog-author-duncan.jpeg b/apps/marketing/public/blog/blog-author-duncan.jpeg
new file mode 100644
index 000000000..a4a52711c
Binary files /dev/null and b/apps/marketing/public/blog/blog-author-duncan.jpeg differ
diff --git a/apps/marketing/src/app/(marketing)/blog/[post]/opengraph-image.tsx b/apps/marketing/src/app/(marketing)/blog/[post]/opengraph-image.tsx
new file mode 100644
index 000000000..f9987dd27
--- /dev/null
+++ b/apps/marketing/src/app/(marketing)/blog/[post]/opengraph-image.tsx
@@ -0,0 +1,76 @@
+import { ImageResponse } from 'next/server';
+
+import { allBlogPosts } from 'contentlayer/generated';
+
+export const runtime = 'edge';
+
+export const size = {
+ width: 1200,
+ height: 630,
+};
+
+export const contentType = 'image/png';
+
+type BlogPostOpenGraphImageProps = {
+ params: { post: string };
+};
+
+export default async function BlogPostOpenGraphImage({ params }: BlogPostOpenGraphImageProps) {
+ const blogPost = allBlogPosts.find((post) => post._raw.flattenedPath === `blog/${params.post}`);
+
+ if (!blogPost) {
+ return null;
+ }
+
+ // The long urls are needed for a compiler optimisation on the Next.js side, lifting this up
+ // to a constant will break og image generation.
+ const [interBold, interRegular, backgroundImage, logoImage] = await Promise.all([
+ fetch(new URL('./../../../../assets/inter-bold.ttf', import.meta.url)).then(async (res) =>
+ res.arrayBuffer(),
+ ),
+ fetch(new URL('./../../../../assets/inter-regular.ttf', import.meta.url)).then(async (res) =>
+ res.arrayBuffer(),
+ ),
+ fetch(new URL('./../../../../assets/background-blog-og.png', import.meta.url)).then(
+ async (res) => res.arrayBuffer(),
+ ),
+ fetch(new URL('./../../../../../public/logo.png', import.meta.url)).then(async (res) =>
+ res.arrayBuffer(),
+ ),
+ ]);
+
+ return new ImageResponse(
+ (
+
+ {/* @ts-expect-error Lack of typing from ImageResponse */}
+
+
+ {/* @ts-expect-error Lack of typing from ImageResponse */}
+
+
+
+ {blogPost.title}
+
+
+
Written by {blogPost.authorName}
+
+ ),
+ {
+ ...size,
+ fonts: [
+ {
+ name: 'Inter',
+ data: interRegular,
+ style: 'normal',
+ weight: 400,
+ },
+ {
+ name: 'Inter',
+ data: interBold,
+ style: 'normal',
+ weight: 700,
+ },
+ ],
+ },
+ );
+}
diff --git a/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx b/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx
index 5192dec32..757eb8882 100644
--- a/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx
+++ b/apps/marketing/src/app/(marketing)/blog/[post]/page.tsx
@@ -17,7 +17,10 @@ export const generateMetadata = ({ params }: { params: { post: string } }) => {
notFound();
}
- return { title: `Documenso - ${blogPost.title}` };
+ return {
+ title: `Documenso - ${blogPost.title}`,
+ description: blogPost.description,
+ };
};
const mdxComponents: MDXComponents = {
diff --git a/apps/marketing/src/app/(marketing)/claimed/page.tsx b/apps/marketing/src/app/(marketing)/claimed/page.tsx
index ce748006e..b1636e2be 100644
--- a/apps/marketing/src/app/(marketing)/claimed/page.tsx
+++ b/apps/marketing/src/app/(marketing)/claimed/page.tsx
@@ -27,7 +27,11 @@ export type ClaimedPlanPageProps = {
export default async function ClaimedPlanPage({ searchParams = {} }: ClaimedPlanPageProps) {
const { sessionId } = searchParams;
- const session = await stripe.checkout.sessions.retrieve(sessionId as string);
+ if (typeof sessionId !== 'string') {
+ redirect('/');
+ }
+
+ const session = await stripe.checkout.sessions.retrieve(sessionId);
const user = await prisma.user.findFirst({
where: {
@@ -157,8 +161,7 @@ export default async function ClaimedPlanPage({ searchParams = {} }: ClaimedPlan
diff --git a/apps/marketing/src/app/layout.tsx b/apps/marketing/src/app/layout.tsx
index ea21ed3c3..46d9a3d32 100644
--- a/apps/marketing/src/app/layout.tsx
+++ b/apps/marketing/src/app/layout.tsx
@@ -21,12 +21,12 @@ export const metadata = {
description:
'Join Documenso, the open signing infrastructure, and get a 10x better signing experience. Pricing starts at $30/mo. forever! Sign in now and enjoy a faster, smarter, and more beautiful document signing process. Integrates with your favorite tools, customizable, and expandable. Support our mission and become a part of our open-source community.',
type: 'website',
- images: [`${process.env.NEXT_PUBLIC_SITE_URL}/opengraph-image.jpg`],
+ images: [`${process.env.NEXT_PUBLIC_MARKETING_URL}/opengraph-image.jpg`],
},
twitter: {
site: '@documenso',
card: 'summary_large_image',
- images: [`${process.env.NEXT_PUBLIC_SITE_URL}/opengraph-image.jpg`],
+ images: [`${process.env.NEXT_PUBLIC_MARKETING_URL}/opengraph-image.jpg`],
description:
'Join Documenso, the open signing infrastructure, and get a 10x better signing experience. Pricing starts at $30/mo. forever! Sign in now and enjoy a faster, smarter, and more beautiful document signing process. Integrates with your favorite tools, customizable, and expandable. Support our mission and become a part of our open-source community.',
},
diff --git a/apps/marketing/src/assets/background-blog-og.png b/apps/marketing/src/assets/background-blog-og.png
new file mode 100644
index 000000000..d5d48a21a
Binary files /dev/null and b/apps/marketing/src/assets/background-blog-og.png differ
diff --git a/apps/marketing/src/assets/inter-bold.ttf b/apps/marketing/src/assets/inter-bold.ttf
new file mode 100644
index 000000000..8e82c70d1
Binary files /dev/null and b/apps/marketing/src/assets/inter-bold.ttf differ
diff --git a/apps/marketing/src/assets/inter-regular.ttf b/apps/marketing/src/assets/inter-regular.ttf
new file mode 100644
index 000000000..8d4eebf20
Binary files /dev/null and b/apps/marketing/src/assets/inter-regular.ttf differ
diff --git a/apps/marketing/src/components/(marketing)/footer.tsx b/apps/marketing/src/components/(marketing)/footer.tsx
index 6ae66a0a4..ab0dd6e24 100644
--- a/apps/marketing/src/components/(marketing)/footer.tsx
+++ b/apps/marketing/src/components/(marketing)/footer.tsx
@@ -9,6 +9,22 @@ import { cn } from '@documenso/ui/lib/utils';
export type FooterProps = HTMLAttributes;
+const SOCIAL_LINKS = [
+ { href: 'https://twitter.com/documenso', icon: },
+ { href: 'https://github.com/documenso/documenso', icon: },
+ { href: 'https://documen.so/discord', icon: },
+];
+
+const FOOTER_LINKS = [
+ { href: '/pricing', text: 'Pricing' },
+ { href: '/blog', text: 'Blog' },
+ { href: '/open', text: 'Open' },
+ { href: 'https://shop.documenso.com', text: 'Shop', target: '_blank' },
+ { href: 'https://status.documenso.com', text: 'Status', target: '_blank' },
+ { href: 'mailto:support@documenso.com', text: 'Support' },
+ { href: '/privacy', text: 'Privacy' },
+];
+
export const Footer = ({ className, ...props }: FooterProps) => {
return (
- Our mission is to create an open signing infrastructure that empowers the world,
- enabling businesses to embrace openness, cooperation, and transparency. We believe
- that signing, as a fundamental act, should embody these values. By offering an
- open-source signing solution, we aim to make document signing accessible, transparent,
- and trustworthy.
-
-
-
- Through our platform, called Documenso, we strive to earn your trust by allowing
- self-hosting and providing complete visibility into its inner workings. We value
- inclusivity and foster an environment where diverse perspectives and contributions are
- welcomed, even though we may not implement them all.
-
-
-
- At Documenso, we envision a web-enabled future for business and contracts, and we are
- committed to being the leading provider of open signing infrastructure. By combining
- exceptional product design with open-source principles, we aim to deliver a robust and
- well-designed application that exceeds your expectations.
-
-
-
- We understand that exceptional products are born from exceptional communities, and we
- invite you to join our open-source community. Your contributions, whether technical or
- non-technical, will help shape the future of signing. Together, we can create a better
- future for everyone.
-
-
-
- Today we invite you to join us on this journey: By signing this mission statement you
- signal your support of Documenso's mission{' '}
-
- (in a non-legally binding, but heartfelt way)
- {' '}
- and lock in the early supporter plan for forever, including everything we build this
- year.
-
-
-
-
Timur & Lucas
-
-
-
- Timur Ercan & Lucas Smith
-
Co-Founders, Documenso
-
-
-
-
-
- );
-};
diff --git a/apps/web/src/components/(marketing)/open-build-template-bento.tsx b/apps/web/src/components/(marketing)/open-build-template-bento.tsx
deleted file mode 100644
index e7920500b..000000000
--- a/apps/web/src/components/(marketing)/open-build-template-bento.tsx
+++ /dev/null
@@ -1,74 +0,0 @@
-import { HTMLAttributes } from 'react';
-
-import Image from 'next/image';
-
-import { cn } from '@documenso/ui/lib/utils';
-import { Card, CardContent } from '@documenso/ui/primitives/card';
-
-import backgroundPattern from '~/assets/background-pattern.png';
-import cardBuildFigure from '~/assets/card-build-figure.png';
-import cardOpenFigure from '~/assets/card-open-figure.png';
-import cardTemplateFigure from '~/assets/card-template-figure.png';
-
-export type OpenBuildTemplateBentoProps = HTMLAttributes;
-
-export const OpenBuildTemplateBento = ({ className, ...props }: OpenBuildTemplateBentoProps) => {
- return (
-
-
-
-
-
- Truly your own.
- Customise and expand.
-
-
-
-
-
-
- Open Source or Hosted.
- It’s up to you. Either clone our repository or rely on our easy to use hosting
- solution.
-
-
-
-
-
-
-
-
-
-
-
- Build on top.
- Make it your own through advanced customization and adjustability.
-
-
-
-
-
-
-
-
-
-
-
- Template Store (Soon).
- Choose a template from the community app store. Or submit your own template for others
- to use.
-
+
+## Activity
+
+
# Tech
@@ -89,10 +101,6 @@ Documenso is built using awesome open source tech including:
- [Node SignPDF (Digital Signature)](https://github.com/vbuch/node-signpdf)
- [React-PDF for viewing PDFs](https://github.com/wojtekmaj/react-pdf)
- [PDF-Lib for PDF manipulation](https://github.com/Hopding/pdf-lib)
-- [Zod for schema declaration and validation](https://zod.dev/)
-- [Lucide React for icons in React app](https://lucide.dev/)
-- [Framer Motion for motion library](https://www.framer.com/motion/)
-- [Radix UI for component library](https://www.radix-ui.com/)
- Check out `/package.json` and `/apps/web/package.json` for more
- Support for [opensignpdf (requires Java on server)](https://github.com/open-pdf-sign) is currently planned.
@@ -135,37 +143,47 @@ Your database will also be available on port `54320`. You can connect to it usin
## Developer Setup
+### Manual Setup
+
Follow these steps to setup documenso on you local machine:
- [Clone the repository](https://help.github.com/articles/cloning-a-repository/) it to your local device.
```sh
git clone https://github.com/documenso/documenso
```
-- Run 
-
-