GoatCounter is an open source web analytics platform available as a hosted service or self-hosted app

Related tags

go golang analytics
Overview

Awesome Humane Tech

GoatCounter is an open source web analytics platform available as a hosted service (free for non-commercial use) or self-hosted app. It aims to offer easy to use and meaningful privacy-friendly web analytics as an alternative to Google Analytics or Matomo.

There are two ways to run this: as hosted service on goatcounter.com, free for non-commercial use, or run it on your own server. The source code is completely Open Source/Free Software, and it can be self-hosted without restrictions.

See docs/rationale.markdown for some more details on the "why?" of this project.

There's a live demo at https://stats.arp242.net.

Please consider contributing financially if you're self-hosting GoatCounter so I can pay my rent :-) GoatCounter is sponsored by a grant from NLnet's NGI Zero PET fund.

Features

  • Privacy-aware; doesn’t track users with unique identifiers and doesn't need a GDPR notice. Fine-grained control over which data is collected. Also see the privacy policy and GDPR consent notices.

  • Lightweight and fast; adds just ~3.5K of extra data to your site. Also has JavaScript-free "tracking pixel" option, or you can use it from your application's middleware or import from logfiles.

  • Identify unique visits without cookies using a non-identifiable hash (technical details).

  • Keeps useful statistics such as browser information, location, and screen size. Keep track of referring sites and campaigns.

  • Easy; if you've been confused by the myriad of options and flexibility of Google Analytics and Matomo that you don't need then GoatCounter will be a breath of fresh air.

  • Accessibility is a high-priority feature, and the interface works well with assistive technology such as screen readers.

  • 100% committed to open source; you can see exactly what the code does and make improvements, or self-host it for any purpose.

  • Own your data; you can always export all data and cancel at any time.

  • Integrate on your site with just a single script tag:

    ">
    
    
  • The JavaScript integration is a good option for most, but you can also use a no-JavaScript image-based tracker, integrate it in your backend middleware, or parse log files.

Getting data in to GoatCounter

There are three ways:

  1. Add the JavaScript code on your site; this is the easiest and most common method. Detailed documentation for this is available at https://www.goatcounter.com/code

  2. Integrate in your middleware; send data to GoatCounter by calling the API from your backend server middleware. Detailed documentation for this is available at https://www.goatcounter.com/api#backend-integration

  3. Parse logfiles. GoatCounter can parse logfiles from nginx, Apache, CloudFront, or any other HTTP middleware or proxy. See goatcounter help import for detailed documentation on this.

Running your own

The release page has binaries for Linux amd64, arm, and arm64. These are statically compiled, contain everything you need, and should work in pretty much any Linux environment. The only other thing you need is somewhere to store a SQLite database file or a PostgreSQL connection.

GoatCounter should run on any platform supported by Go, but there are no binaries for them (yet); you'll have to build from source if you want to run it on e.g. FreeBSD or macOS.

Note this README is for the latest master; use the release-2.0 branch for the 2.0 README.

Generally speaking only the latest release is supported, although critical fixes (security, data loss, etc.) may get backported to previous releases.

Deploy scripts and such

Building from source

You need Go 1.16 or newer and a C compiler (for SQLite). If you compile it with CGO_ENABLED=0 you don't need a C compiler but can only use PostgreSQL.

Compile from source with:

$ git clone -b release-2.0 https://github.com/zgoat/goatcounter.git
$ cd goatcounter
$ go build -ldflags="-X zgo.at/goatcounter.Version=$(git log -n1 --format='%h_%cI')" ./cmd/goatcounter

You'll now have a goatcounter binary in the current directory.

The -ldflags=[..] sets the version; this isn't strictly required as such, but it's recommended as it's used to "bust" the cache for static files and may also be useful later when reporting bugs. This can be any string and doesn't follow any particular format, you can also set this to the current date or banana or anything you want really.

To build a fully statically linked binary:

$ go build -tags osusergo,netgo,sqlite_omit_load_extension \
    -ldflags="-X zgo.at/goatcounter.Version=$(git log -n1 --format='%h_%cI') -extldflags=-static" \
    ./cmd/goatcounter

It's recommended to use the latest release as in the above command. The master branch should be reasonably stable but no guarantees, and sometimes I don't write detailed release/upgrade notes until the actual release so you may run in to surprises.

You can compile goatcounter without cgo if you're planning to use PostgreSQL and don't use SQLite:

$ CGO_ENABLED=0 go build \
    -ldflags="-X zgo.at/goatcounter.Version=$(git log -n1 --format='%h_%cI')" \
    ./cmd/goatcounter

Functionally it doesn't matter too much, but builds will be a bit easier and faster as it won't require a C compiler.

Running

You can start a server with:

$ goatcounter serve

The default is to use an SQLite database at ./db/goatcounter.sqlite3, which will be created if it doesn't exist yet. See the -db flag and goatcounter help db to customize this.

Both SQLite and PostgreSQL are supported. SQLite should work well for most smaller sites, but PostgreSQL gives better performance. There are some benchmarks over here to give some indication of what performance to expect from SQLite and PostgreSQL.

GoatCounter will listen on port *:80 and *:443 by default. You don't need to run it as root and can grant the appropriate permissions on Linux with:

$ setcap 'cap_net_bind_service=+ep' goatcounter

Listening on a different port can be a bit tricky due to the ACME/Let's Encrypt certificate generation; goatcounter help listen documents this in depth.

You can create new sites with the db create site command:

$ goatcounter db create site -vhost stats.example.com -user.email [email protected]

This will ask for a password for your new account; you can also add a password on the commandline with -password. You must also pass the -db flag here if you use something other than the default.

Updating

You may need to run the database migrations when updating. Use goatcounter serve -automigrate to always run all pending migrations on startup. This is the easiest way, although arguably not the "best" way.

Use goatcounter migrate or goatcounter migrate all to manually run migrations; generally you want to upload the new version, run migrations while the old one is still running, and then restart so the new version takes effect.

Use goatcounter migrate pending to get a list of pending migrations, or goatcounter migrate list to show all migrations.

PostgreSQL

To use PostgreSQL run GoatCounter with a custom -db flag; for example:

$ goatcounter serve -db 'postgresql://dbname=goatcounter'
$ goatcounter serve -db 'postgresql://host=/run/postgresql dbname=goatcounter sslmode=disable'

This follows the format in the psql CLI; you can also use the PG* environment variables:

$ PGDATABASE=goatcounter DBHOST=/run/postgresql goatcounter serve -db 'postgresql://'

See goatcounter help db and the pq docs for more details.

Development/testing

You can start a test/development server with:

$ goatcounter serve -dev

The -dev flag makes some small things a bit more convenient for development; TLS is disabled by default, it will listen on localhost:8081, the application will automatically restart on recompiles, templates and static files will be read directly from the filesystem, and a few other minor changes.

See .github/CONTRIBUTING.markdown for more details on how to run a development server, write patches, etc.

Various aggregate data files are available at https://www.goatcounter.com/data

Issues
  • Reports over 1 month are empty

    Reports over 1 month are empty

    Hello,

    Using the Team Kodi account, I cannot seem to generate a report greater than 1 month. When I attempt to generate a report for 3 months I end up with one of the following screens.

    Is this a known issue?

    goat1

    goat2

    opened by KarellenX 20
  • How do you run this through a proxy?

    How do you run this through a proxy?

    I'm not really familiar with Go, but I've run go build -ldflags="-X main.version=$(git log -n1 --format='%h_%cI')" ./cmd/goatcounter and it was able to download the files.

    It seems the next step is to run goatcounter serve but that just returns a goatcounter not found

    opened by Okozzie 20
  • Add/expand self-hosting guide

    Add/expand self-hosting guide

    I think a step-by-step guide with examples for setting up goatcounter on a fresh VPS to a production-ready state could go a long way with making self-hosting more approachable. I've just finished setting it up myself and here are a few particular issues I encountered:

    1. time.LoadLocation(...) which is used by your tz module (used in goatcounter) expects that system has a list of all timezones available, and fails with a quite cryptic error message when it cannot find it: panic: tz.init: unknown time zone Asia/Kabul (or some other random timezone). This requires something like apk add tzdata or apt install tzdata (depending on distro) to fix.

    2. When calling goatcounter create, it's not intuitive for a first-time user that -domain is the domain where goatcounter runs, not the tracked domain. Also, I'm still not sure what the -parent parameter does, and the -h description doesn't really help. Also, I think -createdb should be the default, as otherwise it just panics saying it couldn't find the database file. serve creates the DB automatically, I don't see a reason why create shouldn't.

    3. Adding some basic instructions on how to setup goatcounter to run automatically using systemd would be nice for first timers, although I understand that it's out of scope for goatcounter. :)

    Few articles I found around the internet, which may serve as an inspiration:

    • https://rgth.co/blog/replacing-google-analytics-with-goatcounter/
    • https://daulton.ca/2021/01/openbsd-goatcounter-server/

    Lastly, I wanna say thanks for goatcounter - I love both the philosophy and UI. If it proves to work well over time, I'll gladly send some donations your way. :)

    opened by MatejKafka 19
  • Docker

    Docker

    I would love to make a pull request but I'm really not quiet strong with the Dockerness. I think having a Dockerfile, docker-compose.yml, and an official docker image might make it easier for certain people to use and work on goatcounter.

    opened by Th3Whit3Wolf 15
  • Show State/Province Locations

    Show State/Province Locations

    I stumbled upon GoatCounter yesterday and am very impressed. (So long Matomo.) The only missing information I noticed is location by state/province. In Canada, USA, China etc, I think it's useful to be able to see what state people are visiting from.

    enhancement 
    opened by cwmke 15
  • >100% stats numbers

    >100% stats numbers

    bug 
    opened by Am-per-Sand 15
  • Site switcher in top-left corner looks squished/weird once you have a lot of sites

    Site switcher in top-left corner looks squished/weird once you have a lot of sites

    Is there a way to apply our own custom CSS to the dashboard?

    https://rgth.co/blog/replacing-google-analytics-with-goatcounter/

    I followed the tutorial above, where are the files located for the doing so?

    Thanks

    opened by Okozzie 14
  • [HELP] -stripe: must be set.

    [HELP] -stripe: must be set.

    Creating goatcounter binary from the newest source codes, and trying to starte it, then goatcounter print help messages and doesn't start.

    Does -stripe flag become essential? If so, how is necessary keys created? What parameters should I assign in Stripe? Could you tell me step-by-step procedure?

    support 
    opened by mzch 14
  • Issues associated with tailing logs.. goatcounter help import  documentation needs updates

    Issues associated with tailing logs.. goatcounter help import documentation needs updates

    Hello,

    The ability to tail HTTP server logs attracted me to goatcounter. So I decided to test it out. My HTTP server, Caddy 2, is notoriously terrible at logging (it logs timestamps as floating point numbers like 1615274947.5499396, among other things :facepalm: )

    Well, that's because its designed to log structured data. Whatever. That's fine, I can live with that. According to this "legendary" thread, if you want to format caddy logs for human consumption (or oldschool plaintext machine consumption, in the case of goatcounter), you are supposed to "just use jq": https://caddy.community/t/making-caddy-logs-more-readable/7565

    Ok. Well, whatever, I can live with that. I like jq and I know how to use it. So I ran some tests and came up with what I believe is the right jq command to transform the JSON Caddy 2 server logs into goatcounter's combined-vhost format:

    	// Combined format; used by default in Apache, nginx.
    	//
    	// 127.0.0.1    user -  [10/Oct/2000:13:55:36 -0700] "GET     /path HTTP/1.1" 200     2326  "https://ref" "Mozilla/5.0"
    	// $remote_addr $ignore [$datetime]                  "$method $path $http"    $status $size "$referrer"   "$user_agent"
    	Combined      = `$remote_addr $ignore [$datetime] "$method $path $http" $status $size "$referrer" "$user_agent"`
    	CombinedVhost = `$host:` + Combined
    

    This is my jq script, with the input data and output data:

    {"level":"info","ts":1615272162.1549003,"logger":"http.log.access","msg":"handled request","request":{"remote_addr":"192.168.0.25:47046","proto":"HTTP/2.0","method":"GET","host":"goatcounter.beta.sequentialread.com","uri":"/pikaday.js?v=dev","headers":{"User-Agent":["Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0"],"Accept":["*/*"],"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, deflate, br"],"Referer":["https://goatcounter.beta.sequentialread.com/"],"Cookie":["key=20210309-1zfeBLAHBLAHBLAHBLAHBLAHBLAHBALHm1"],"Te":["trailers"]},"tls":{"resumed":true,"version":772,"cipher_suite":4867,"proto":"h2","proto_mutual":true,"server_name":"goatcounter.beta.sequentialread.com"}},"common_log":"192.168.0.25 - - [09/Mar/2021:06:42:42 +0000] \"GET /pikaday.js?v=dev HTTP/2.0\" 200 25545","duration":0.004892355,"size":25545,"status":200,"resp_headers":{"Access-Control-Allow-Origin":["*"],"Cache-Control":["no-store,no-cache"],"Content-Type":["text/javascript; charset=utf-8"],"Date":["Tue, 09 Mar 2021 06:42:42 GMT"],"Server":["Caddy"]}}
    
    
    jq -r '"\(.request.host):\(.common_log) \"\(.request.headers.Referer[0])\" \"\(.request.headers."User-Agent"[0])\""'
    
    
    goatcounter.beta.sequentialread.com:192.168.0.25 - - [09/Mar/2021:06:42:42 +0000] "GET /pikaday.js?v=dev HTTP/2.0" 200 25545 "https://goatcounter.beta.sequentialread.com/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0"
    

    I read in goatcounter help import that I can import a log file from stdin, so the first thing I tried was

    #!/bin/sh -e
    
    logfilepath="$1"
    
    tail -f "$logfilepath"  \
      | jq -r '"\(.request.host):\(.common_log) \"\(.request.headers.Referer[0])\" \"\(.request.headers."User-Agent"[0])\""' \
      | /app/goatcounter import -format combined-vhost -
    

    I configured it in docker compose like this:

      goatcounter-log-publisher:
        image: sequentialread/goatcounter:1.4.2-12
        restart: always
        entrypoint: ["/bin/sh"]
        command: ["/app/tail_caddy_json_log.sh", "/caddylog/caddy-goatcounter.log"]
        extra_hosts:
          - "goatcounter.beta.sequentialread.com:172.17.0.1"
        volumes:
          - type: bind
            source: ./goatcounter/db
            target: /app/db
          - type: bind
            source: ./caddy/log
            target: /caddylog
        networks:
          - caddy
    
    

    This bit here:

        extra_hosts:
          - "goatcounter.beta.sequentialread.com:172.17.0.1"
    

    is like a hosts file entry inside the container, its overriding all DNS requests for goatcounter.beta.sequentialread.com to resolve to 172.17.0.1. 172.17.0.1 is the default docker bridge IP address, so in other words, 172.17.0.1 is the IP address of the host from the container's perspective. It's like a docker version of 127.0.0.1.

    I had to add this to the config because initially, the goatcounter-log-publisher could not reach the goatcounter server over http:

    [email protected]:/dockremap/sequentialread# docker logs sequentialread_goatcounter-log-publisher_1
    Get "https://goatcounter.beta.sequentialread.com/api/v0/count/api/v0/me": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
    

    After I added the extra_hosts parameter, the TCP connection error was gone and I was greeted by a new error:

    [email protected]:/dockremap/sequentialread# docker logs sequentialread_goatcounter-log-publisher_1
    https://goatcounter.beta.sequentialread.com/api/v0/count/api/v0/me: 404 Not Found: packed file not found: "/api/v0/count/api/v0/me"
    
    

    This looked like a malformed URL to me, as if the code was not constructing the url to call correctly. This happened when I ran this setup with goatcounter v1.4.2.

    I figured maybe this bug is already fixed, so I tried updating to master, but now the silly thing wont run at all, the cli flags parser doesn't like stdin input:

    [email protected]:/dockremap/sequentialread# docker logs sequentialread_goatcounter-log-publisher_1
    goatcounter: unknown flag: "-"
    
    

    Its 2am here so I think I'm going to leave this for now but if no one else can look at it I'll take a crack at fixing myself in the AM.. I'd like this feature to work & it seems like a simple fix maybe

    opened by ForestJohnson 12
  • Improve UA parsing

    Improve UA parsing

    github.com/mssola/user_agent isn't always reliable. I took a look in to fixing it, but it's not so easy.

    I just noticed there's also https://github.com/avct/uasurfer, which may give better results.

    This would also allow storing just the calculated result ("Firefox 70.0") instead of the full UA string, which sometimes contains quite a lot of information.

    enhancement 
    opened by arp242 12
  • Feature Request: Page Load Time

    Feature Request: Page Load Time

    In contrast to other self-hosted analytics like Shynet and plausible, goatcounter doesn't measure page load time. This seems to be a basic feature necessary for troubleshooting and measuring performance. Would be aprecciated if you added it.

    opened by blox814123 0
  • Create an OpenBSD package (port) of GoatCounter

    Create an OpenBSD package (port) of GoatCounter

    Because OpenBSD does not have GoatCounter port yet, I want to create one.

    I would like to ask if I'm allowed to do so?

    Is there any suggestion for me?

    The plan will look like:

    • Port name: goatcounter
    • Version: 2.0.4 (taken from tag)
    • User data will be located at: /var/goatcounter
    • Have a configuration file for GoatCounter Arguments at /etc/goatcounter.conf
    • How about the License?
    opened by cavoirom 5
  • Unwanted = (equal) follows url path

    Unwanted = (equal) follows url path

    Hi, url's in my dynamic app look like this {website}/?path/to/somewhere

    When tracked by goat, they are always listed with an equal at the end: {website}/?path/to/somewhere=

    Likely because goat assumes it's a query parameter with a value and appends = even if the value is empty. This breaks the link back to our app. Surely it should be able to accept paths with queries without values assigned? It's not unusual to use the entire query as the path, as it's most pleasing.

    opened by mjau-mjau 3
  • Postgresql: Options are supported during 'db schema-pgsql' but not 'db create site'

    Postgresql: Options are supported during 'db schema-pgsql' but not 'db create site'

    Following this tutorial, I created a custom schema that was only for site related databases. I noticed that setting custom schemas only works for populating a database but creating a site ignores that completely.

    How to reproduce

    1. Populate the database goatdb with a schema called site as per documented:

    goatcounter db schema-pgsql -db 'postgresql://dbname=goatdb user=goat password=<my password> sslmode=disable options=--search_path=site' | psql

    1. Create a new site:

    goatcounter db create site -vhost <domain> -user.email <email> -db 'postgresql://dbname=goatdb user=goat password=<my password> sslmode=disable options=--search_path=site'

    Error Message

    goatcounter: zdb.Connect: zdb.NewMigrate: create version table: pq: no schema has been selected to create in

    opened by bedwardly-down 5
  • 1.4.2 -> 2.0.4 migration failure

    1.4.2 -> 2.0.4 migration failure

    When updating my private instance from 1.4.2 to 2.0.4, the goatcounter serve -automigrate part fails with this:

    goatcounter: zdb.Connect: zdb.Migrate.Run: running "2020-08-28-5-paths-ua-fk": pq: insert or update on table "user_agents" violates foreign key constraint "user_agents_browser_id_fkey"

    opened by hristoast 4
  • Access controls per site

    Access controls per site

    Via email:

    Make it possible to restrict additional users to one or more specific sites configured in GoatCounter. Useful if you are managing several completely separate sites and want certain users to only be able to view or administer one of those sites. This could potentially be a feature that would be limited to paid plans, since it mostly makes sense in a commercial context.

    This is actually already implemented, kind-of. But I didn't like how the UI worked and wasn't sure how much desire for this there was in the first place, so I just commented that out.

    opened by arp242 0
  • Change alert on attempt to view future statistics to something nicer

    Change alert on attempt to view future statistics to something nicer

    Bumping a TODO: https://github.com/zgoat/goatcounter/blob/990313f70c279c7ca4439f14968e040748958112/public/dashboard.js#L118 (although I found this before)

    I agree that it's intrusive - very little sites use alerts now, they look kinda scammy, and draw too much attention.

    On grepping through the codebase a bit more, it seems alert( pops up a few times.

    What do you propose as an alternative?

    opened by skuzzymiglet 2
  • i18n support

    i18n support

    Hey Martin,

    I really love what you did here. It's a really nice tool. I'm using the goatcounter the first time and for my customer I need to translate it in german, because english is not "allowed". Are you planning on internationalization/multi-language support any soon? Or is my only option currently to translate all files. I was also thinking about creating a pull request with some i18n-package.

    Thank you already, Marco

    opened by mheumann 16
  • goatcounter does not count pageviews when using Next.js Link

    goatcounter does not count pageviews when using Next.js Link

    I recently started using goatcounter and I think that count.js does not take into account the method used by the Next.js Link component to navigate.

    The default behavior of the Link component is to push a new URL into the history stack.

    With this component, navigating does not trigger a DOMContentLoaded event, causing pageviews only to be counted either when the user visits the website for the first time, or a page is reloaded.

    // count.js (Line 106-112)
    // Run function after DOM is loaded.
    	var on_load = function(f) {
    		if (document.body === null)
    			document.addEventListener('DOMContentLoaded', function() { f() }, false)
    		else
    			f()
    	}
    

    Is this behavior the best and only way to count pageviews, or can count.js be modified to take into account this type of navigation? What about using the DOMContentLoaded OR document.location property to detect when then url changes and trigger the count? Or perhaps using the History API to detect when a new item is pushed to the history.

    I wish I could have created a pull request, but I have more questions than answers right now.

    opened by diegoramosxyz 3
  • Current master requires regular restarts in order for stats to update

    Current master requires regular restarts in order for stats to update

    I am trying out goatcounter using latest master built like this:

    CGO_ENABLED=0 go build \
      -tags osusergo,netgo,sqlite_omit_load_extension \
      -ldflags="-X zgo.at/goatcounter.Version=$(git log -n1 --format='%h_%cI') -extldflags=-static" \
      ./cmd/goatcounter
    

    And running it with:

    PGPASSWORD=[REDACTED] goatcounter serve -listen '*:8080' -tls http -db postgres://[email protected][REDACTED]/goatcounter -automigrate
    

    It is behind a proxy that terminates TLS.

    Everything appears to work fine at first; /count.js and /count are served and the dashboard is served, but most information doesn't appear in the dashboard until the process is terminated and restarted. Some pages do start to appear in the list under Pages, but with pageview counts of 0 and without corresponding bars in the graph. No country, browser or screen size information is shown.

    Within a few seconds of terminating goatcounter and restarting it, all of the pageview counts, countries, browsers and screen sizes appear, but after it is restarted, new page views are not processed for this information (though they do appear to be counted in the total, because the percentages of the existing information reduce over time).

    opened by jbg 9
Releases(v2.0.4)
  • v2.0.4(Apr 13, 2021)

  • v2.0.3(Apr 2, 2021)

  • v2.0.2(Apr 1, 2021)

    • Fix migration order.

    • Don't display the expected "Memstore.Init: json: cannot unmarshal number / into Go struct field storedSession.paths of type int64" error log on startup; this got displayed once, but was a bit confusing.

    • Display a message on startup after the first update to direct people towards the 2.0 release notes and "goatcounter reindex".

    Be sure to read the release notes for 2.0.0 as there are some incompatibilities and manual actions!

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v2.0.2-linux-amd64.gz(8.22 MB)
    goatcounter-v2.0.2-linux-arm.gz(7.38 MB)
    goatcounter-v2.0.2-linux-arm64.gz(7.33 MB)
  • v2.0.1(Mar 30, 2021)

    • Fix migrations 🀦 They worked when they were written, but a bunch of things changed in GoatCounter and some older ones didn't run any more.

    • Add -test flag to goatcounter db migrate to rollback a migration, so it's easier to test if migrations will run correctly without actually changing the database.

    Be sure to read the release notes for 2.0.0 as there are some incompatibilities and manual actions!

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v2.0.1-linux-amd64.gz(8.22 MB)
    goatcounter-v2.0.1-linux-arm.gz(7.38 MB)
    goatcounter-v2.0.1-linux-arm64.gz(7.33 MB)
  • v2.0.0(Mar 30, 2021)

    The version is bumped to 2.0 because this contains a number of incompatible changes: several CLI commands got changed, and it includes some large database migrations – running them is a bit more complex than the standard migrations.

    An overview of incompatible changes:

    • There are some rather large changes to the database layout for better efficiency; this means:

      • Somewhat faster queries.
      • Greatly reduced disk space requirements for the database.
      • The Browsers, systems, size, and location stats are filtered if you enter something in "filter paths". Previously this always displayed the site totals.
      • "Purge path" now works as expected for all stats.
      • Easier to add new statistics in the future.

      To update:

      1. You must first update to 1.4.2 and run all migrations from that. Updating from older versions directly to 2.0.0 will not work!

      2. Run the migrations with goatcounter serve -automigrate or goatcounter migrate.

      3. You probably want to manually run VACUUM (or VACUUM FULL for PostgreSQL) after the migration to free up unused rows. This isn't strictly required, but frees up disk space, and removes some of the autovacuum pressure that will run in the background.

      4. Run goatcounter reindex.

      All of this may take a while if you've got a lot of data. For about 500,000 pageviews it takes about 3 minutes on SQLite, but if you've got millions of pageviews it may take an hour or more.

      If you want to keep pageviews while this is running you can:

      1. Write it to a logfile from a proxy or temporary HTTP server and run goatcounter import on this after the migrations are done.

      2. Use goatcounter buffer.

    • goatcounter migrate is now goatcounter db migrate. It also behaves a bit different:

      • goatcounter db migrate pending lists only pending migrations, and will use exit code 1 if there are any pending migrations.
      • goatcounter db migrate list lists all migrations, always exits with 0.
    • If you use PostgreSQL you need PostgreSQL 12 or newer; this was already the case before and you could run in to some edge cases where things didn't work, but this is enforced now.

    • The none value got removed from the -tls flag; use tls=http to not serve TLS. This was confusingly named as you can do -tls=none,acme to still generate ACME certificates, but none implies that nothing is done.

    • goatcounter create is now goatcounter db site create, and some flags got changed:

      • -domain is now -vhost.
      • -parent is now -link.
      • -email is now -user.email.
      • -password is now -user.password.
    • The -port flag for goatcounter serve is renamed to -public-port. This should clarify that this isn't the listen port, but just the port GoatCounter is publicly accessible on.

    • The -site flag got removed from goatcounter import; you can now only use -url to set a GoatCounter site to import to. The automagic API key creation was more confusing than anything else.

      You can use goatcounter db create apitoken to create an API key from the CLI.

    • If you build from source, the build flag to set the version changed from:

      -ldflags="-X main.version=..."
      

      to:

      -ldflags="-X zgo.at/goatcounter.Version=..."
      
    • The CSV export format was increased to 2; it now includes the parsed browser and system values in addition to the User-Agent header. Version 2.0 will not be able to import the older exports from version 1.

    Other changes:

    • You can read pageviews from logfiles with the goatcounter import command; you can also send pageviews to goatcounter.com with this (you don’t need to self-host it). See goatcounter help import and the site code documentation for details.

    • You can now create multiple users; before there was always a single one. You can add users in Settings β†’ Users.

      As a consequence, "Site settings" and "User preferences" are now split in to two screens. The Settings button in the top-right now displays only site settings, and clicking on your email address in the top right displays user preferences, which every user can configure to their liking.

    • You can now configure what's displayed on the dashboard, in what order, and configure some aspects of various "widgets". You can set it in User preferences β†’ Dashboard. Some settings from the main settings page have moved there.

    • You can save a default view for the dashboard. Instead of always loading the last week by default, you can now configure it to load the last month, or view by day, or anything you want really.

    • You can choose which data to collect; you can disable collecting any User-Agent, location, Referrer information.

    • Ability to record state/province/district in addition to country, so it records "US-TX" or "NL-NB" instead of "United States" or "Netherlands".

      This option can be disabled separately from recording the country (enabled by default) and you can set which countries to record it for (defaults to US, RU, CH).

      This requires specifying the path to a GeoIP City database, which isn't included since it's ~30M.

    • There are now stable count.v*.js scripts that can use subresource integrity. See the integration code for a list and hashes.

    • You can use data-goatcounter-settings on the <script> tag to load the settings (requires count.v2.js or newer).

    • New goatcounter buffer command; this allows buffering of pageviews in case the backend is down, running migrations, etc. See goatcounter help buffer for more information.

    • The database for PostgreSQL is now created automatically; you no longer need to do this manually.

    • You can copy settings from a site to other sites in Settings β†’ Sites.

    • Add goatcounter db command; you can now edit and delete sites, users, and API keys from the CLI. The create and migrate commands are now merged in to this as subcommands.

    • Add a gcbench utility for inserting random pageviews in a database; for testing and comparing performance. This might be useful for end-users too in some cases, for example to see how much performance difference SQLite and PostgreSQL will give you, or to test if frobbing with server settings makes a difference:

      $ go run ./cmd/gcbench -db sqlite://db/gcbench.sqlite3 -ndays=90 -npaths=100 -nhits=1_000_000
      $ go run ./cmd/gcbench -db postgresql://dbname=gcbench -ndays=90 -npaths=100 -nhits=1_000_000
      

      Right now it doesn't try super-hard to simulate read-world usage patterns: the distribution is always uniform, but it still gives a reasonably accurate indication for comparison purposes.

    • Many other minor changes and improvements.

    • For changes since RC1 see: https://github.com/zgoat/goatcounter/compare/v2.0.0-rc1...v2.0.0

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v2.0.0-linux-amd64.gz(8.22 MB)
    goatcounter-v2.0.0-linux-arm.gz(7.38 MB)
    goatcounter-v2.0.0-linux-arm64.gz(7.32 MB)
  • v2.0.0-rc1(Mar 20, 2021)

    The version is bumped to 2.0 because this contains a number of incompatible changes: several CLI commands got changed, and it includes some large database migrations – running them is a bit more complex than the standard migrations.

    Because this includes so many changes I'll do a Release Candidate first. Please report issues if you have any problems! Barring unexpected large issues I'll do a 2.0 release next week or so.

    An overview of incompatible changes:

    • There are some rather large changes to the database layout for better efficiency; this means:

      • Somewhat faster queries.
      • Greatly reduced disk space requirements for the database.
      • The Browsers, systems, size, and location stats are filtered if you enter something in "filter paths". Previously this always displayed the site totals.
      • "Purge path" now works as expected for all stats.
      • Easier to add new statistics in the future.

      To update:

      1. You must first update to 1.4.2 and run all migrations from that. Updating from older versions directly to 2.0.0 will not work!

      2. Run the migrations with goatcounter serve -automigrate or goatcounter migrate.

      3. You probably want to manually run VACUUM (or VACUUM FULL for PostgreSQL) after the migration to free up unused rows. This isn't strictly required, but frees up disk space, and removes some of the autovacuum pressure that will run in the background.

      4. Run goatcounter reindex.

      All of this may take a while if you've got a lot of data. For about 500,000 pageviews it takes about 3 minutes on SQLite, but if you've got millions of pageviews it may take an hour or more.

      If you want to keep pageviews while this is running you can:

      1. Write it to a logfile from a proxy or temporary HTTP server and run goatcounter import on this after the migrations are done.

      2. Use goatcounter buffer.

    • goatcounter migrate is now goatcounter db migrate. It also behaves a bit different:

      • goatcounter db migrate pending lists only pending migrations, and will use exit code 1 if there are any pending migrations.
      • goatcounter db migrate list lists all migrations, always exits with 0.
    • The none value got removed from the -tls flag; use tls=http to not serve TLS. This was confusingly named as you can do -tls=none,acme to still generate ACME certificates, but none implies that nothing is done.

    • goatcounter create is now goatcounter db site create, and some flags got changed:

      • -domain is now -vhost.
      • -parent is now -link.
      • -email is now -user.email.
      • -password is now -user.password.
    • The -port flag for goatcounter serve is renamed to -public-port. This should clarify that this isn't the listen port, but just the port GoatCounter is publicly accessible on.

    • The -site flag got removed from goatcounter import; you can now only use -url to set a GoatCounter site to import to. The automagic API key creation was more confusing than anything else.

      You can use goatcounter db create apitoken to create an API key from the CLI.

    • If you build from source, the build flag to set the version changed from:

      -ldflags="-X main.version=..."
      

      to:

      -ldflags="-X zgo.at/goatcounter.Version=..."
      
    • The CSV export format was increased to 2; it now includes the parsed browser and system values in addition to the User-Agent header. Version 2.0 will not be able to import the older exports from version 1.

    Other changes:

    • You can read pageviews from logfiles with the goatcounter import command; you can also send pageviews to goatcounter.com with this (you don’t need to self-host it). See goatcounter help import and the site code documentation for details.

    • You can now create multiple users; before there was always a single one. You can add users in Settings β†’ Users.

      As a consequence, "Site settings" and "User preferences" are now split in to two screens. The Settings button in the top-right now displays only site settings, and clicking on your email address in the top right displays user preferences, which every user can configure to their liking.

    • You can now configure what's displayed on the dashboard, in what order, and configure some aspects of various "widgets". You can set it in User preferences β†’ Dashboard. Some settings from the main settings page have moved there.

    • You can save a default view for the dashboard. Instead of always loading the last week by default, you can now configure it to load the last month, or view by day, or anything you want really.

    • You can choose which data to collect; you can disable collecting any User-Agent, location, Referrer information.

    • Ability to record state/province/district in addition to country, so it records "US-TX" or "NL-NB" instead of "United States" or "Netherlands".

      This option can be disabled separately from recording the country (enabled by default) and you can set which countries to record it for (defaults to US, RU, CH).

      This requires specifying the path to a GeoIP City database, which isn't included since it's ~30M.

    • There are now stable count.v*.js scripts that can use subresource integrity. See the integration code for a list and hashes.

    • You can use data-goatcounter-settings on the <script> tag to load the settings (requires count.v2.js or newer).

    • New goatcounter buffer command; this allows buffering of pageviews in case the backend is down, running migrations, etc. See goatcounter help buffer for more information.

    • The database for PostgreSQL is now created automatically; you no longer need to do this manually.

    • You can copy settings from a site to other sites in Settings β†’ Sites.

    • Add goatcounter db command; you can now edit and delete sites, users, and API keys from the CLI. The create and migrate commands are now merged in to this as subcommands.

    • Add a gcbench utility for inserting random pageviews in a database; for testing and comparing performance. This might be useful for end-users too in some cases, for example to see how much performance difference SQLite and PostgreSQL will give you, or to test if frobbing with server settings makes a difference:

      $ go run ./cmd/gcbench -db sqlite://db/gcbench.sqlite3 -ndays=90 -npaths=100 -nhits=1_000_000
      $ go run ./cmd/gcbench -db postgresql://dbname=gcbench -ndays=90 -npaths=100 -nhits=1_000_000
      

      Right now it doesn't try super-hard to simulate read-world usage patterns: the distribution is always uniform, but it still gives a reasonably accurate indication for comparison purposes.

    • Many other minor changes and improvements.

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v2.0.0-rc1-linux-amd64.gz(8.18 MB)
    goatcounter-v2.0.0-rc1-linux-arm.gz(7.35 MB)
    goatcounter-v2.0.0-rc1-linux-arm64.gz(7.29 MB)
  • v1.4.2(Nov 10, 2020)

  • v1.4.1(Sep 4, 2020)

  • v1.4.0(Aug 24, 2020)

    Major changes:

    • Change defaults for -listen (#336)

      The default for the -listen flag changed from localhost:8081 to :443, which is probably a better and less confusing default for most people. There is also some more detailed docs available in goatcounter help listen.

    • Set Cache-Control header for static files (#348)

      The Cache-Control header is now set for static files. Since the "cache busting" happens based on the goatcounter version it's now recommended to set this if you're compiling GoatCounter yourself. See the updated README for instructions.

    • Add multi-factor auth (#306)

      TOTP-based multi-factor auth is now supported.

    • Better export, export API, add import feature (#316, #318, #329)

      You can now import the CSV exports, useful for migrating from self-hosted to goatcounter.com or vice versa, or for migrating from other systems. There is a web interface and a goatcounter import command.

      The export now supports a "pagination cursor", so you can export only rows you didn't previously export. This is especially useful with the new export API. which should make it easy to sync GoatCounter data with another external platform.

      See http://goatcounter.com/api for details on the export API.

    • API for sending pageviews (#357)

      Doing that with the regular /count is actually quite painful, as you quickly run in to ratelimits, need to set specific headers, etc. Adding an API endpoint for that makes things much easier.

    • API for creating and editing additional sites (#361)

    • Some redesigns (#324, #315, #321 #320)

      The "Totals" is now placed below the Pages; I think it makes more sense there. The Y-axis for the totals is now also independent. There's also been a quite a few restylings.

    • Add "text view" mode (#359)

      View your data as a simple table without too much graphics; only the main "Pages" overview is implemented for now.

    • Make it easier to skip your own views (#290)

      Previously this required adding custom code, but now loading any page with #toggle-goatcounter added will enable/disable the GoatCounter tracking for that browser.

    • Can now manage "additional sites" from self-hosted GoatCounter (#363)

      This wasn't possible before for no other reason than laziness on my part πŸ™ƒ

    • public/count.js is now ISC licensed (#309)

      Previously the EUPL applied, which is fairly restrictive and may prevent people from including/self-hosting the count.js script.

    • Add goatcounter db command

      This is mostly useful for writing deploy scripts: goatcounter db schema-sqlite prints the SQLite schema, schema-pgsql prints the PostgreSQL schema, and goatcounter db test tests if the database exists.

    • Session hashes are no longer persisted to the database

      This is kind of an internal change, but session hashes are now stored in memory only and never recorded to the database. There's no real reason to persistently store this information, and this is a (small) privacy/GDPR compliance improvement.

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v1.4.0-linux-amd64.gz(7.56 MB)
    goatcounter-v1.4.0-linux-arm.gz(6.80 MB)
    goatcounter-v1.4.0-linux-arm64.gz(6.80 MB)
  • v1.3.2(Jul 17, 2020)

    This is a small fix to set some server http timeouts; this is especially relevant if you run GoatCounter "directly" internet-facing, without using a proxy such as HAPRoxy, Varnish, etc.

    When using GoatCounter directly internet-facing it's liable to keep connections around for far too long, exhausting the max. number of open file descriptors, especially with "idle" HTTP/2 connections which, unlike HTTP/1.1 Keep-Alive don't have an explicit timeout.

    This isn't much of a problem if you're using a proxy in front of it, as most will have some timeouts set by default (unlike Go, which has no timeouts at all by default).

    For the backend interface, keeping a long timeout makes sense; it reduces overhead on requests (TLS setup alone can be >200ms), but for the /count request we typically want a much shorter timeout.

    Unfortunately, configuring timeouts per-endpoint isn't really supported at this point, although some possible workarounds are mentioned in 1, it's all pretty ugly. We can add "Connection: close" to just close the connection, which is probably much better for almost all cases than keeping a connection open since most people only visit a single page, and keeping a connection open in the off-chance they click somewhere again probably isn't really worth it.

    And setting any timeout is better than setting no timeout at all!

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v1.3.2-linux-amd64.gz(7.55 MB)
    goatcounter-v1.3.2-linux-arm.gz(6.85 MB)
    goatcounter-v1.3.2-linux-arm64.gz(6.84 MB)
  • v1.3.1(Jul 4, 2020)

    Fixes for SQLite concurrency issues

    In some busy workloads various SQLite operations would fail due to "locked tables"; most of this is related to the session code:

    • On every pageview a new session is either read (OK) or written (LOCK!)
    • At the same time, the cron may be writing data to the db (LOCK!)

    On smaller instances this isn't much of an issue since everything is fast enough to not lock for too long, but on longer instances this can be a problem.

    Setting SetMaxOpenConns(1) solves this by limiting the connections writing to the database.

    Also set the default journal mode to WAL, which should give better performance. Both of this is done in the zgo.at/zdb update.

    Add "goatcounter help db" to document database usage a bit better.

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v1.3.1-linux-amd64.gz(7.55 MB)
    goatcounter-v1.3.1-linux-arm.gz(6.85 MB)
    goatcounter-v1.3.1-linux-arm64.gz(6.84 MB)
  • v1.3.0(Jun 1, 2020)

    Note: this release contains quite a few database migrations; they make take a minute to run (depending on your table size), and you may want to run a VACUUM afterwards.

    • Remove email auth, replace -auth with -email-from (#263, #270)

      As mentioned in the 1.2 release the email authentication is now removed. You can still reset the password for old accounts.

      Since the email auth no longer exists the -auth parameter no longer makes sense. It's now replaced with -email-from, which can be set to just an email address.

      Action required: if you set the email address with -auth you'll have to change it to -email-from.

    • Add OS stats, improve accuracy of browser stats (#261)

      GoatCounter now tracks the OS/platform in addition to just the browser, and the accuracy of the browser stats should be improved.

      Action required: you'll need to populate the system_stats table:

      $ goatcounter reindex -table system_stats
      

      If you want to process all browser stats with the new logic too, then use this instead:

      $ goatcounter reindex -table system_stats,browser_stats
      
    • Improve performance (#265, #273, #274)

      Increase performance by quite a bit on large sites and time ranges.

    • Remove the per-path scaling (#267)

      Previously GoatCounter would scale the Y-axis different for every path in the dashboard, but this was more confusing than helpful. It's now always scaled to the maximum of all paths in the selected date range and filter, with a field to scale it lower on-demand if desired.

    • Add totals overview (#271)

      Add chart with totals for the selected date range and filter.

    • Add goatcounter.url(), goatcounter.filter() (#272, #253)

      Adds two new methods to the count.js script so it's easier to use write own implementation. In addition the script will now issue a console.warn() if a request isn't being counted for some reason.

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v1.3.0-linux-amd64.gz(7.55 MB)
    goatcounter-v1.3.0-linux-arm.gz(6.86 MB)
    goatcounter-v1.3.0-linux-arm64.gz(6.84 MB)
  • v1.2.0(May 18, 2020)

    There are a number of changes in 1.2, and a few which require a bit of action when updating. Also see: https://www.arp242.net/goatcounter-1.2.html

    • Password authentication (#232)

      The email-based authentication has been deprecated in favour of password authentication.

      Action required Use the interface to set a password (you will get a notification about this). Email authentication still works, but will be removed in the next release, after which updating the password will be tricky.

    • Unique visit tracking (#212)

      GoatCounter now tracks unique visits (without using cookies).

      Technical documentation about the implementation is in doc/sessions.markdown.

      There are two ways to display the older stats:

      1. Do nothing; meaning that "visits" will be 0 for previous date ranges.

      2. Assign a new 'session' to every hit, so that unique visits will be the same as the number of pageviews.

      Doing option 2 is a potentially expensive database operation and not everyone may care so it's not done automatically; instructions for doing this are:

      • SQLite (do not do this on a running system; as far as I can tell there's no good way to get the next sequence ID while incrementing it):

        delete from sessions;
        update hits set session=id, first_visit=1;
        update sqlite_sequence set seq = (select max(session) from hits) where name='sessions';
        
      • PostgreSQL:

        update hits set session=nextval('sessions_id_seq'), first_visit=1;
        

      And then run goatcounter reindex.

    • Improve bot detection (#219)

      The bot detection is now improved; this will be applied to older pageviews in the database with a migration, but the cached statistics aren't updated automatically (as it can take a while for larger sites). Use the reindex command to fully update older pageviews (this is entirely optional).

    • Track events (#215)

      There is now better support to track events; see the updated documentation on the Site Code page for details.

    • Better support for campaigns (#238)

      There is now a "campaign parameters" setting; if the URL matches one of these parameters it will be set as the referrer (overriding the Referer header).

      The default is utm_campaign, utm_source, ref.

    • Better export (#221)

      The export was a quick feature added in the first version, but didn't scale well to larger sites with a lot of pageviews. This now works well for any number of pageviews.

    • Many small improvements and bug fixes

      It's almost 2 months of work, and there have been many small changes, fixes, and improvements. I didn’t keep track of them all πŸ˜…

    Source code(tar.gz)
    Source code(zip)
    goatcounter-v1.2.0-linux-amd64.gz(7.39 MB)
    goatcounter-v1.2.0-linux-arm.gz(6.73 MB)
    goatcounter-v1.2.0-linux-arm64.gz(6.71 MB)
  • v1.1.1(Mar 27, 2020)

    • Small bugfix release which fixes some small issues and improves a few small documentation issues. List of changes: https://github.com/zgoat/goatcounter/compare/v1.1.0...v1.1.1

    • The biggest change is that the saas command no longer works (and is no longer documented). It was only ever useful for hosting goatcounter.com, and has a number of assumptions and hard-coded values.

      If you're using saas, then you can migrate to serve by setting a custom domain (sites.cname) for all the sites. The serve command should work after that.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Mar 18, 2020)

    This list is not comprehensive, and only lists new features and major changes.

    • Incompatible Improve CLI UX (#154, #173, #175, #181)

      The entire CLI has been redone; the original wasn't very user-friendly for self-hosting. See goatcounter help for the full docs, but in brief:

      o Use "goatcounter serve" instead of just "goatcounter".
      o Create new sites with "goatcounter create".
      o Good support for TLS hosting and ACME certificates (see -tls flag).
      o Invert -prod to -dev (i.e. just drop -prod for production services, add -dev for development).
      o -smtp flag is no longer required.
      o -dbconnect                 β†’  -db
      o -pgsql                     β†’  -db postgresql://...
      o -staticdomain              β†’  no longer needed, but if you really want it you can
                                      append to domain: -domain example.com,static.example.com
      o -emailerrors               β†’  -errors mailto:...
      o goatcounter -migrate       β†’  goatcounter migrate
      o goatcounter -migrate auto  β†’  goatcounter serve -automigrate
      
    • Action required Show top referrals (#192)

      To populate the ref_stats and size_stats tables for older data, update first and then run:

      $ goatcounter reindex -confirm -table ref_stats
      $ goatcounter reindex -confirm -table size_stats
      
    • Charts are displayed in local timezone (#155)

    • Add "IgnoreIPs" setting to ignore your own views (#128)

    • Link to paths by adding a new domain setting (#138)

    • Add configurable data retention (#134)

    • Allow configuring the thousands separator (#132)

    • Allow filtering pages in the dashboard (#106)

    • Improve the integration code (#122)

    • Allow sending emails without a relay (#184)

    • Add get_query() to count.js to get query parameter (#199)

    • Allow viewing the charts by day, instead of only by hour (#169)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Jan 13, 2020)

Analytics box a simple and privacy focused analytics tool written in go like google analytics

Analytics box is analytics tool like google analytics but instead of ripping user's privacy off them like google it respects their privacy and doesn't collect any unnecessary information.

Ketan Iralepatil 2 Sep 20, 2021
Minimalist open-source web analytics

Zero-effort web analytics. This is a self-hosted open-source version of Nullitics.

null 54 Sep 30, 2021
A code generator that turns plain old Go services into RPC-enabled (micro)services with robust HTTP APIs.

Frodo Frodo is a code generator and runtime library that helps you write RPC-enabled (micro) services and APIs. It parses the interfaces/structs/comme

Rob Signorelli 13 Sep 27, 2021
Remark42 is a self-hosted, lightweight, and simple comment engine

Remark42 is a self-hosted, lightweight, and simple (yet functional) comment engine, which doesn't spy on users. It can be embedded into blogs, articles or any other place where readers add comments.

Umputun 3.1k Oct 18, 2021
Example patterns for distributed service

Cloud Native Tulisan ini akan mengulas hasil pembelajaran dari beberapa sumber #learn-from-books. Dan terinspirasi dari obrolan The Pursuit of Product

Zeihan Aulia 14 Sep 8, 2021
Lazyload module with golang

Install & Use Other installation options Disable global-sidecar Use cluster unique global-sidecar Introduction of features Automatic ServiceFence gene

null 2 Oct 15, 2021
Mouthful is a self-hosted alternative to Disqus.

Mouthful is a lightweight commenting server written in GO and Preact. It's a self hosted alternative

Viktoras 698 Oct 11, 2021
Extract structured data from web sites. Web sites scraping.

Dataflow kit Dataflow kit ("DFK") is a Web Scraping framework for Gophers. It extracts data from web pages, following the specified CSS Selectors. You

Dmitry Narizhnykh 485 Oct 24, 2021
Focalboard is an open source, self-hosted alternative to Trello, Notion, and Asana.

Focalboard Like what you see? ?? Give us a GitHub Star! ⭐ Focalboard is an open source, self-hosted alternative to Trello, Notion, and Asana. It helps

Mattermost 5.3k Oct 23, 2021
Self-hosted video-hosting website and video archival manager for Niconico, Bilibili, and Youtube

Self-hosted video-hosting website and video archival manager for Niconico, Bilibili, and Youtube

null 418 Oct 16, 2021
πŸ”₯ Hugo website builder, Hugo themes & Hugo CMS. No code, build with widgets!

Wowchemy: the website builder for Hugo Join 750,000+ Sites. No Code. Easily Create Future-Proof Websites ✏️ ?? ?? ?? 1. Create any kind of website

Wowchemy 6k Oct 23, 2021
listmonk is a standalone high performance, self-hosted newsletter and mailing list manager with a modern dashboard. Single binary app.

listmonk is a standalone, self-hosted, newsletter and mailing list manager. It is fast, feature-rich, and packed into a single binary. It uses a PostgreSQL database as its data store.

Kailash Nadh 6.8k Oct 23, 2021
Hammond is a self hosted vehicle management system to track fuel and other expenses related to all of your vehicles.

Hammond is a self hosted vehicle management system to track fuel and other expenses related to all of your vehicles. It supports multiple users sharing multiple vehicles. It is the logical successor to Clarkson which has not been updated for quite some time now.

Akhil Gupta 193 Oct 22, 2021
GoTTY - Share your terminal as a web application

GoTTY - Share your terminal as a web application GoTTY is a simple command line tool that turns your CLI tools into web applications. Installation Fro

Soren L. Hansen 1.3k Oct 23, 2021
IP geolocation web server

freegeoip NOTE: as of April 2018 this repository is no longer active. Please visit https://github.com/apilayer/freegeoip/ for the current version. Thi

Alexandre Fiori 4.8k Oct 16, 2021
Beautifully simple single author blog in Go - derived from Bear Blog.

Polar Bear Blog ??‍❄️ Lightweight blogging system for a single author. Written in Go and deploys to your own GCP project with a few commands. It's a d

Joseph Spurrier 21 Sep 26, 2021
Soong is the replacement for the old Android make-based build system

Soong Soong is the replacement for the old Android make-based build system. It replaces Android.mk files with Android.bp files, which are JSON-like si

null 0 Oct 10, 2021
listmonk is a standalone, self-hosted, newsletter and mailing list manager

listmonk is a standalone, self-hosted, newsletter and mailing list manager. It is fast, feature-rich, and packed into a single binary. It uses a Postg

Super-Smile 1 Oct 19, 2021
Go Server/API boilerplate using best practices DDD CQRS ES gRPC

Go Server/API boilerplate using best practices DDD CQRS ES gRPC

RafaΕ‚ Lorenz 481 Oct 15, 2021