Convert Figma logo to code with AI

getmeli logomeli

Platform for deploying static sites and frontend applications easily. Automatic SSL, deploy previews, reverse proxy, and more.

2,414
97
2,414
41

Top Related Projects

27,495

The flexible backend for all your projects 🐰 Turn your DB into a headless CMS, admin panels, or apps with a custom UI, instant APIs, auth & more.

63,346

🚀 Strapi is the leading open-source headless CMS. It’s 100% JavaScript/TypeScript, fully customizable, and developer-first.

17,877

A Git-based CMS for Static Site Generators

47,740

Independent technology for modern publishing, memberships, subscriptions and newsletters.

49,335

:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby

75,317

The world’s fastest framework for building websites.

Quick Overview

Meli is an open-source platform for deploying static sites and frontend applications. It provides a simple and efficient way to manage and deploy multiple sites, offering features like automatic SSL, custom domains, and team collaboration.

Pros

  • Easy deployment process with Git integration
  • Automatic SSL certificate management
  • Support for custom domains and subdomains
  • Team collaboration features for managing multiple sites

Cons

  • Limited documentation and community support
  • Requires self-hosting, which may be challenging for some users
  • Fewer integrations compared to some commercial alternatives
  • May require additional setup for advanced use cases

Getting Started

To get started with Meli, follow these steps:

  1. Install Docker and Docker Compose on your server
  2. Clone the Meli repository:
    git clone https://github.com/getmeli/meli.git
    
  3. Navigate to the cloned directory:
    cd meli
    
  4. Copy the example environment file:
    cp .env.example .env
    
  5. Edit the .env file to configure your settings
  6. Start Meli using Docker Compose:
    docker-compose up -d
    
  7. Access the Meli dashboard at http://your-server-ip:3000

For more detailed instructions and configuration options, refer to the official Meli documentation.

Competitor Comparisons

27,495

The flexible backend for all your projects 🐰 Turn your DB into a headless CMS, admin panels, or apps with a custom UI, instant APIs, auth & more.

Pros of Directus

  • More comprehensive content management system with a full-featured admin panel
  • Supports multiple database types (MySQL, PostgreSQL, SQLite, etc.)
  • Larger community and more frequent updates

Cons of Directus

  • Heavier and more complex setup compared to Meli's focused approach
  • May be overkill for simple static site hosting needs
  • Steeper learning curve for developers new to headless CMS systems

Code Comparison

Meli configuration (simplified):

version: '3'
services:
  meli:
    image: getmeli/meli:latest
    environment:
      - MELI_SITE_URL=https://example.com

Directus configuration (simplified):

{
  "database": {
    "client": "pg",
    "connection": {
      "host": "127.0.0.1",
      "port": 5432,
      "database": "directus",
      "user": "directus",
      "password": "directus"
    }
  }
}

Meli focuses on simple static site hosting, while Directus provides a more comprehensive content management solution. Meli's configuration is typically simpler, reflecting its focused approach. Directus requires more detailed setup but offers greater flexibility in database choices and content management features.

63,346

🚀 Strapi is the leading open-source headless CMS. It’s 100% JavaScript/TypeScript, fully customizable, and developer-first.

Pros of Strapi

  • More mature and widely adopted, with a larger community and ecosystem
  • Offers a user-friendly admin panel for content management
  • Supports multiple databases (SQLite, PostgreSQL, MySQL, MongoDB)

Cons of Strapi

  • Can be resource-intensive for larger projects
  • Steeper learning curve for developers new to headless CMS

Code Comparison

Strapi (JavaScript):

module.exports = ({ env }) => ({
  host: env('HOST', '0.0.0.0'),
  port: env.int('PORT', 1337),
  admin: {
    auth: {
      secret: env('ADMIN_JWT_SECRET'),
    },
  },
});

Meli (Go):

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run()
}

Key Differences

  • Strapi is a headless CMS, while Meli is a platform for deploying static sites and frontend applications
  • Strapi is built with Node.js, whereas Meli is written in Go
  • Strapi focuses on content management and API creation, while Meli emphasizes deployment and hosting

Use Cases

  • Choose Strapi for projects requiring a flexible content management system with a robust API
  • Opt for Meli when you need a simple, performant solution for deploying and hosting static sites or frontend applications
17,877

A Git-based CMS for Static Site Generators

Pros of Decap CMS

  • More established project with a larger community and contributor base
  • Extensive documentation and tutorials available
  • Supports a wide range of static site generators and platforms

Cons of Decap CMS

  • Limited to static site content management
  • Requires more setup and configuration compared to Meli
  • Less flexible for custom workflows and integrations

Code Comparison

Decap CMS (config.yml):

backend:
  name: git-gateway
  branch: main
collections:
  - name: "blog"
    label: "Blog"
    folder: "content/blog"
    create: true
    fields:
      - {label: "Title", name: "title", widget: "string"}
      - {label: "Body", name: "body", widget: "markdown"}

Meli (meli.json):

{
  "sites": [
    {
      "name": "my-site",
      "url": "https://example.com",
      "branch": "main",
      "env": {
        "NODE_ENV": "production"
      }
    }
  ]
}

Decap CMS focuses on content management for static sites, while Meli is a more general-purpose deployment and hosting platform. Decap CMS offers a user-friendly interface for content editors, whereas Meli provides streamlined deployment workflows for developers. The code examples showcase the configuration differences, with Decap CMS centered around content structure and Meli focused on deployment settings.

47,740

Independent technology for modern publishing, memberships, subscriptions and newsletters.

Pros of Ghost

  • More mature and widely adopted platform with a larger community
  • Extensive plugin ecosystem and themes available
  • Built-in SEO tools and native integrations with popular services

Cons of Ghost

  • Heavier resource requirements, especially for larger sites
  • Less flexibility in terms of customization compared to Meli
  • Steeper learning curve for developers new to the platform

Code Comparison

Ghost (JavaScript):

const ghost = require('ghost');

ghost().then((ghostServer) => {
    ghostServer.start();
});

Meli (Go):

package main

import "github.com/getmeli/meli/cmd"

func main() {
    cmd.Execute()
}

Key Differences

  • Ghost is primarily focused on content publishing and blogging, while Meli is a more versatile static site and web app hosting platform
  • Ghost uses Node.js and is written in JavaScript, whereas Meli is built with Go
  • Meli offers features like automatic HTTPS, custom domains, and team collaboration out of the box
  • Ghost provides a more comprehensive content management system with built-in editors and user management

Both platforms have their strengths, with Ghost excelling in content-focused websites and Meli offering more flexibility for various web projects. The choice between them depends on specific project requirements and developer preferences.

49,335

:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby

Pros of Jekyll

  • Mature and widely adopted static site generator with a large community
  • Extensive plugin ecosystem and themes available
  • Native support for GitHub Pages, making deployment simple

Cons of Jekyll

  • Requires Ruby knowledge for advanced customization
  • Slower build times for large sites compared to newer alternatives
  • Limited built-in features for dynamic content

Code Comparison

Jekyll (config.yml):

title: My Jekyll Site
description: A static site generator
url: "https://example.com"
theme: minima
plugins:
  - jekyll-feed

Meli (meli.config.js):

module.exports = {
  site: {
    title: 'My Meli Site',
    description: 'A modern static site generator',
  },
  build: {
    outDir: 'public',
  },
};

While Jekyll uses a YAML configuration file, Meli opts for a JavaScript-based configuration, allowing for more flexibility and programmatic options. Jekyll's configuration focuses on site-wide settings and plugin management, whereas Meli's configuration provides more granular control over the build process and site structure.

75,317

The world’s fastest framework for building websites.

Pros of Hugo

  • Mature and widely adopted static site generator with a large community
  • Extremely fast build times, especially for large sites
  • Extensive theme ecosystem and built-in templating system

Cons of Hugo

  • Steeper learning curve, especially for non-technical users
  • Limited dynamic content capabilities without external services
  • Requires local installation and command-line usage for content management

Code Comparison

Hugo (Go):

{{ range .Pages }}
  <h2>{{ .Title }}</h2>
  {{ .Content }}
{{ end }}

Meli (JavaScript):

sites.map(site => (
  <div key={site.id}>
    <h2>{site.name}</h2>
    <p>{site.description}</p>
  </div>
))

Key Differences

  • Hugo is a static site generator, while Meli is a deployment and hosting platform
  • Hugo focuses on content generation, Meli on site management and deployment
  • Hugo requires local development, Meli offers a web-based interface
  • Hugo is written in Go, Meli in JavaScript (React)
  • Hugo has a larger community and ecosystem, Meli is newer with fewer resources

Both tools serve different purposes in the web development workflow. Hugo excels at generating static sites, while Meli simplifies deployment and hosting processes.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

meli-logo

meli

Open source platform for deploying static sites and frontend applications.

Docs (proudly hosted on Meli !) - Twitter

Discord

We are looking for maintainers ! Interested to take over ? Shoot us an email at info@charlie-bravo.be

Meli demo screenshot

Getting started

Want to change the way you ship front-end, forever ? Let's get started !

  1. Head to our installation instructions
  2. After you have installed Meli and have successfully logged in:
    1. Create a site in your dashboard, say my-site
    2. Upload a release with the @getmeli/meli CLI
    3. Setup my-domain.com to point to your Meli server at my-site.mymeli.com

Features

Development

  1. Run docker-compose -f ./docker-compose-dev.yml up -d
  2. Configure server/.env (copy server/.env.example to start with)
  3. Run npm i && npm start

You can now browse at http://localhost:8080:

  • http://localhost:8080/ => UI
  • http://localhost:8080/api, http://localhost:8080/auth, http://localhost:8080/system and http://localhost:8080/socket.io => API
  • http://loopback.sh => your sites will be served here

DNS config

You need to configure your machine to allow wildcard domains for development. We've got a few ways to do this.

Use loopback.sh

We've configured loopback.sh to point to 127.0.0.1, so you can develop with it. Update your .env.

MELI_SITES_URL=loopback.sh

Your sites will be served at *.loopback.sh.

Pros: simple, no config required Cons: you need to be connected to the internet

Using /etc/hosts

Unfortunately, /etc/hosts doesn't support wildcard domains, so you'll need to edit /etc/hosts for every site added to Meli:

127.0.0.1 my-site.test
127.0.0.1 my-channel.my-site.test

Pros: simple, can develop without internet Cons: have to reconfigure every time you add a site

Using dnsmasq

brew install dnsmasq

# tell dsnmasq to point *.test to 127.0.0.1
echo "address=/test/127.0.0.1" > /usr/local/etc/dnsmasq.conf

# start daemon
brew services start dnsmasq

# make OSX point to dnsmasq
sudo mkdir -p /etc/resolver

# tell os x to point *.test to 127.0.0.1
sudo echo "nameserver 127.0.0.1" > /etc/resolver/test

ping hello.test

Your sites will be served at *.test.

Pros: you don't need to be connected to the internet, no need to reconfigure /etc/hosts Cons: a bit complex, config required

License

The words "Open Source" in our README refer to the definition given by many well-recognized dictionaries of various languages, which is " used to describe software for which the original source code is made available to anyone".

The words "Open Source" in our license, introduced and written by MariaDB, refer to the definition given by the Open Source Foundation. Though we adopted this license to make it easier for users to recognize it, we disagree with this sentence being part of it and are working on this matter.

The BSL license allows you to modify, share, redistribute and use this software for free with the only condition that you do not run a competing SAAS service based on this project, which would both be unfair and jeopardize the options of making this tool sustainable.

We chose the BSL license because we believe it is fair for both users and maintainers. It allows us to secure a monetization path while providing proper support in the long run. Also, our license converts automatically within 4 years of each release to a license officially recognized by the Open Source Foundation, which secures a way for the community to see the sole restriction removed.

We are aware of the debate around the BSL conflicting with rule number 9 of the definition given by the Open Source Foundation. We do believe that, in specific cases, this rule should be relaxed as it prevents platform maintainers to secure a path to sustaining the development of their tool and support of their community while preventing large players from running unfair competition by leveraging their infrastructure and name. There is sufficient material on this matter available on the internet for users to make up their mind.

As a side note, rule number 9 conflicts similarly with the BSL than with the GPL3.0, which does restrict the creation of other software in its own way, while still being officially recognized by the Open Source Foundation.