[GH-ISSUE #129] Suggestions for self-hosted deployment and APIs #45

Closed
opened 2026-03-01 14:39:42 +03:00 by kerem · 2 comments
Owner

Originally created by @lilixxs on GitHub (Feb 16, 2025).
Original GitHub issue: https://github.com/arikchakma/maily.to/issues/129

This is the best free email editor I have ever used

  • Simple but efficient UI (editor + mail sender information + template configuration, no ADs or other non-related elements)
  • The editing function is powerful (you can easily get started as long as you have used a block-like text editor, eg. Notion)
  • The effect is very good (it render very perfect mail on both mobile and computer screens)

Briefly reviewed the source code and found that this project has some sustainability issues

  • Now all templates, images, and configurations are stored in the author's private supabase, which may be very costly in the long run and pose security risks.
  • Currently, it is only possible to log in through the web page, lacking the ability to link with other automation tools.

Are the following aspects considered in the future plan?

  • Privatization deployment (such as creating Docker images) can open the Supabase path, thus supporting private database deployment and solving the problem 1 mentioned above
  • Add API interface to solve problem 2 above

Some suggestion on APIs:

It seems that the following interfaces are needed

  • Maily.to platform authentication: authentication for users to obtain template & config information (if it is a private deployment, permission authentication can be simplified, for example, just providing a bearer token is enough)
  • Get template list: like taemplate id, name and so on, template id info is essetial for following mail send API
  • Access, store, and modify mail server configuration information (since the endpoint configuration has now been provided, it means that this configuration has already become a general REST interface configuration)
  • Check the correctness of the configuration information (you can use the following interface to send a test email, and if the test email is sent successfully, it means the configuration is correct)
  • Select the interface for sending emails using the corresponding template
    • "test email" can be a system template to integrated "Sending test email" function into this API
    • This interface should also provide variable replacement functionality, togeter with some specific marked syntax in the editor, like conditional expressions {{ XXX }} (widely applys many lowcode platform), using input params to replace these marks so that the template should work as a real TEMPLATE

Other interfaces that can be considered

  • Maily.to API management: eg. bearer token management
  • Template file management: copy template, delete template (In terms of the integrity of the project interface, it is necessary, but not urgent, this should not be a high-frequency function, and it can also be used directly on the web interface)
  • Template content editing (but I also feel it's not very necessary; if you want a nice-looking interface, it's better to edit the template in the editor and then send it using the template)

Ideal work flow (my personal opinion only)

n8n (self-hosted) -----------------------> maily.to (self-hosted) --------------> resend.com / other compatible email sending platforms or tools
|                                        |                                        |
(collect information  &                  (generate mails with                     (handle actual mail sending stuff)
listen to message triggers)              beautiful templates)
Originally created by @lilixxs on GitHub (Feb 16, 2025). Original GitHub issue: https://github.com/arikchakma/maily.to/issues/129 ## This is the best free email editor I have ever used - Simple but efficient UI (editor + mail sender information + template configuration, no ADs or other non-related elements) - The editing function is powerful (you can easily get started as long as you have used a block-like text editor, eg. Notion) - The effect is very good (it render very perfect mail on both mobile and computer screens) ## Briefly reviewed the source code and found that this project has some sustainability issues - Now all templates, images, and configurations are stored in the author's private supabase, which may be very costly in the long run and pose security risks. - Currently, it is only possible to log in through the web page, lacking the ability to link with other automation tools. ## Are the following aspects considered in the future plan? - Privatization deployment (such as creating Docker images) can open the Supabase path, thus supporting private database deployment and solving the problem 1 mentioned above - Add API interface to solve problem 2 above ## Some suggestion on APIs: It seems that the following interfaces are needed - Maily.to platform authentication: authentication for users to obtain template & config information (if it is a private deployment, permission authentication can be simplified, for example, just providing a bearer token is enough) - Get template list: like taemplate id, name and so on, template id info is essetial for following mail send API - Access, store, and modify mail server configuration information (since the endpoint configuration has now been provided, it means that this configuration has already become a general REST interface configuration) - Check the correctness of the configuration information (you can use the following interface to send a test email, and if the test email is sent successfully, it means the configuration is correct) - Select the interface for sending emails using the corresponding template - "test email" can be a system template to integrated "Sending test email" function into this API - This interface should also provide variable replacement functionality, togeter with some specific marked syntax in the editor, like conditional expressions `{{ XXX }}` (widely applys many lowcode platform), using input params to replace these marks so that the template should work as a real TEMPLATE Other interfaces that can be considered - Maily.to API management: eg. bearer token management - Template file management: copy template, delete template (In terms of the integrity of the project interface, it is necessary, but not urgent, this should not be a high-frequency function, and it can also be used directly on the web interface) - Template content editing (but I also feel it's not very necessary; if you want a nice-looking interface, it's better to edit the template in the editor and then send it using the template) ## Ideal work flow (my personal opinion only) ``` n8n (self-hosted) -----------------------> maily.to (self-hosted) --------------> resend.com / other compatible email sending platforms or tools | | | (collect information & (generate mails with (handle actual mail sending stuff) listen to message triggers) beautiful templates) ```
kerem closed this issue 2026-03-01 14:39:42 +03:00
Author
Owner

@arikchakma commented on GitHub (Feb 16, 2025):

Thank you for opening the issue; you read my mind. We have been secretly working on this and should be live by mid-March.

<!-- gh-comment-id:2661413590 --> @arikchakma commented on GitHub (Feb 16, 2025): Thank you for opening the issue; you read my mind. We have been secretly working on this and should be live by mid-March.
Author
Owner

@lilixxs commented on GitHub (Feb 17, 2025):

Alright, I am looking forward to your team's progress. 😊

<!-- gh-comment-id:2661807522 --> @lilixxs commented on GitHub (Feb 17, 2025): Alright, I am looking forward to your team's progress. 😊
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/maily.to#45
No description provided.